perm filename DESCR.RLL[RLL,DBL] blob
sn#642970 filedate 1982-02-13 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00019 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 RLL TALK
C00005 00003 Add/Change to memo, next iteration:
C00009 00004 Short description (for AAAI Article)
C00015 00005 Version of Short PCohen rewrote (June 1980) [Taken from previous page]
C00018 00006 Mailed to NII (LENAT/CC) 18:50 26-June
C00029 00007 Mailed to CSD.NII@SCORE 15:41 3-July
C00041 00008 Received from NII 7-July (essentially final form)
C00051 00009 Sent to DBL fr NLM report - 10 April 1981
C00064 00010 Comparison to Editors
C00066 00011 Language metaphor
C00070 00012 Ref:
C00073 00013 ∂4 Apr 1981 1605-PST CSD.GENESERETH mrs report
C00084 00014 ∂ 14 Jul 1981 2254-PDT KAPLAN at SRI-AI Origins of MRS
C00091 00015 [RLL Section of BES Book - Original - sent to DBL, thence to Waterman]
C00140 00016 [My version, after fix up (after Don, after DBL,from me)]
C00207 00017 [DBL's version, from last page]
C00279 00018 RLL subChapter in BES book
C00301 00019 A list of those additional values which get passed to
C00313 ENDMK
C⊗;
RLL TALK
Hillel metaphor:
"Tell me what's in the Torah, while I stand on one foot."
other fellow -> go away
Hillel -> "Do not do ... " The rest is just example and ...
Similarly what is in RLL-1 is just simple, single idea:
Leave parts of the representation explicit, and modifiable --
using same formalism as what is conventionally called "data".
The rest of just implementation.
This talk will first provide motivation -- why this is a good idea, and
why and how it can, at all, work.
Then specifics of RLL-1 ...
<<Table with missing leg for Problem 1; Hammer and Nail for Soln (rep'n lang)>>
<<Broken cup for Problem 2; Glue for Soln (rep'n lang)>>
Let us pause here and ask why LISP is in such common usage --
what advantages does it have over, say, Fortran (well, we know why not
Fortran) over, say, Pascal or the other "good" (structured) languages?
Answer is clear - Lisp is flexible and adaptable to new situations.
How does this happen: LISP code is identical, in form, to the data
it can use -- they are all S-Expressions. And LISP knows how to deal
with S-expressions in general, and hence can modify code with the
same ease as it can manipulate data in general.
Add/Change to memo, next iteration:
0. Page numbers - there should be a blank page after the title.
1. Glossary:
Language, Representation, Rep'n Language, Semantics
rll, RLL-1,
Slot Type, slot, unit, proposition, class of units, typical member, defaults
2. Example of RLL in action - perhaps spill problem (with its control process)
3. Move much of Section 4.3 (example of defining a new type of slot using HLDefn)
to Appendix A, so this just points there.
4. Further details
FAST-CACHE, FAST-GET for GetValue
Fast-Cache for CacheValue
Fast-Put for PutValue
Add on ways of handling quantification
[Maybe Mike's 13 facts]
Note at end that we are changing it so each unit (well, each KB) knows how to
access its slots, ...
Section numbers of Appendix F, about Functions, mislabeled (with D.2, ...)
"Developped"
Enough for PRIMER - i.e. minimal set of commands the user must know.
(Anne's suggestion)
Present FIRST as static interpreter, then go on to show how that might be changed.
Westfold, Steve [mispelled ...]
What is our purpose -- i.e.
Verification - RLL is a success when ____.
i) Given any new rep'n item, we can nod our head, realizing it could be done
ii) Others abandon their systems, realizing RLL's generality subsumes
such systems
In overview:
There is one major distinction between what the name r..l..l.. implies, and
what this system really is and does. When you modify some part of the
networks which describes/represents VLSI, you do NOT produce a new chip --
that is, the referent of these symbols is, of course, unchanged.
Changes to RLL-1, however, may have more far ranging effects -- the system
itself (that is, what these various symbols are actually describing) are
changed by commands to RLL-1. Like Dorian Grey, changing these symbols
causes their extensions to be altered.
Add: ref to Music Encycl, for Bach; also Dorian Grey
Precise Statement of our goals -
To develop a body of mechanisms (read language) in which one can
represent the components of a RL, and their interactions.
(Components include:
Slots, Inheritance Mechanism, Matchers, Verifiers, ?Semantics? )
Include hierarchy of existing pieces - taken from Klone, KRL, ...,
user can pick and choose
Note it is NOT required that we (explicitly) encode every possible rep'nal
construct -- our goal is to be able to develope such, readily.
Short description (for AAAI Article)
Implementing a complex AI task using begins by designing and building a
suitable representation language, in which to express the primitives of
this domain are easy to express and manipulate. (eg Parsing Trees for NL,
or Experiment Planning for MOLGEN.) The representation language used in
one domain is very seldom borrowed and adaptated to serve for some other
application -- the facilities which were desirable assets for the original
task become limitations elsewhere. Most such languages are therefore
built essentially from scratch -- a very time consuming (and, we believe,
avoidable) task.
Realizing this problem, we built a language in which the components of a
representation language could be described and built, and integrated into
a new representation language. This Representation Language Language,
RLL, provides a body of high level constructs which the user can apply
when designing his new language, [significantly speeding up this first
step.] RLL includes a large library of "representational pieces", e.g.
including the mode of inheritance used by the Examples link of the Units
package, or the A-Kind-Of type of slot associated with FRL. A novice user
can easily design his system by simply choosing the precise amalgamation
of these pieces he wishes. RLL is then responsible for meshing these
parts together, to form a coherent and working whole.
A more advanced user can exploit RLL's mechanisms for designing new parts
-- for example, a new inheritance, or new type of format permissable for a
slot. He could then use these in the system he is building. Once again,
the use of high level operators (such as Create-New-Inheritance-Like(
InstanceOf )) will vastly lessen the time required to construct this
desired language (compared to using, say, CAR, CDR and COND).
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
This research has forced us to examine a variety of issues -- ranging from
"what's in a language" concerns, which asks just what are the constituent
parts of a representation language, to epistomological questions, such as
how to handle intentional objects, or syntactic slots.
The details of how RLL was designed can be found in [Greiner 1980]; and
our proposals for solving many of the outstanding issues and questions are
in [Greiner and Lenat 1980] and [Genesereth and Lenat 1980]. Finally,
Dave Smith's demand paging system, CORLL, frees RLL from InterLisp's 256K
storage limitation.
Ref:
Genesereth, Micheal, and Lenat, Douglas B., "?", HPP Working Paper 80-?,
June 1980.
Greiner, Russell, "A Representation Language
Language", HPP Working Paer 80-9.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", submitted to this AAAI.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, June 1980.
Version of Short PCohen rewrote (June 1980) [Taken from previous page]
Implementing a complex AI task often begins by designing and
building a suitable representation language, in which the primitives
of the domain are easy to express and manipulate. The representation
language used in one domain is seldom borrowed and adapted to
another, because the facilities that were assets for one task become
limitations elsewhere. For this reason, most such languages are built
from scratch. The goal of the RLL effort is to reduce the amount of
time expended in building a representation language, by providing a
Representation Language Language, that is, a language that provides
the user with the components of many representation languages, and
with the ability to integrate them. RLL contains a large library of
"representational pieces", for example, the mode of inheritance used
by the Examples link of the Units package, or the A-Kind-Of type of
slot used in the MIT Frames Representation Language, FRL. A novice
user can easily design a language simply by picking an amalgamation
of pieces; RLL is responsible for meshing them together into a
coherent and working whole. A more advanced user can exploit RLL's
mechanisms for designing new parts, for example, a new mode of
inheritance, or a new type of format for a slot. He could then use
these in the system he is building. The use of high level operators
(e.g. "Create-New-Inheritance-Like(Instance-Of)") will greatly lessen
the time required to construct the desired language.
The RLL system is an ongoing effort. It has recently been
used in two small, internal tasks, an adventure game simulation and
an exploration into a more complete self-description of various of
its parts, using lower level primitives.
Mailed to NII (LENAT/CC) 18:50 26-June
Short description (for NII's HPP Brochure)
Motivation
Implementing a complex AI task usually begins by building such a
representation language. This language is designed to facilitate the
expression and manipulation of the primitives of this particular domain.
Experience has shown that the language used in one domain is seldom
borrowed and adaptated to serve for some other application: The
facilities which were desirable assets for the original task become
limitations elsewhere. Most such languages are built essentially from
scratch -- a very time consuming (and, we believe, avoidable) task.
Task Description
To speed up this first step, we built a language which "knows" about the
components of representation languages in general. This Representation
Language Language, RLL, provides an extendable collection of high level
operators and constructs, which can be used to describe and build such
components. It can then integrate these pieces into a functional, new
representation language. The user can use these functions to design his
"personal" language, capable of dealing with the problems associated with
his specfic domain and application.
RLL's open-ended means there were be an extendable set of possible
representational pieces. The current system knows about slots, modes of
inheritance, specification for functions, etc. (Much of the nomenclature,
such as Unit and Slot, is taken from the UNITS package, described
earlier.) (A sample mode of inheritance is the one associated with the
Examples link of the Units package, which corresponds to "element-of".)
Most operators are methods for defining or refining such pieces. For
example, RLL allows the user to define the "Parents" slot as the union of
the "Mother" and "Father" slots -- that is, (the value of) the "Parents"
slot of an individual is a list consisting of (the value of) that person's
"Mother" slot, and (the value of) his "Father" slot. This brief
definition alone is sufficient to tell RLL everything it needs to know
about this slot. RLL will automatically invalidate the value stored for
Fred's parents if his mother remarries; and know that only some units may
have a Parents slots (viz. those which had both a Mother and Father slot
-- i.e. people).
RLL includes a large library of pre-fabricated "representational pieces".
In fact, a novice can easily design his language by simply choosing the
precise amalgamation of these pieces he wishes. RLL will then mesh these
parts together, to form a coherent and working whole.
A more advanced user can exploit RLL's mechanisms for designing new parts.
The "Father" example above illustrates the ease associated with defining a
new slot; designing a new inheritance, or new type of format is as easy.
As before, the host of high level operators considerably lessens the
complexity associated with constructing and integrating this new piece.
Using these parts (however they were derived,) as tools, the user can then
procede with his main task. If he later discovers limitations in this set
of facilities, he need only redesign the offending components. RLL's high
level operators make such modifications easy to perform; furthermore, RLL
will automatically perform any necessary reformatting of the existing data
to conform to this new, just defined set of conventions.
Current Applications
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
An brief overview of RLL's goals can be found in [Greiner & Lenat]. This
is expanded in [Greiner 1980], which illustrating many additional aspects
of RLL's design and implementation. Finally, an important stand-alone
submodule of RLL is its demand paging system, CORLL, which frees RLL from
InterLisp's 256K storage limitation. (See [Smith 1980].)
Ref:
Greiner, Russell, "A Representation Language Language", HPP Working Paper
80-9, June 1980.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", AAAI Conference, Stanford, 1980.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, June 1980.
∂Date: 27 Jun 1980 1442-PDT
From: Nii at SUMEX-AIM
Subject: Re: Short RLL Description
To: RDG at SU-AI
cc: lenat
In response to your message sent 26 Jun 1980 1850-PDT
Russ,
The piece you wrote is really nice and is much appreciated.
I'll go over it Doug to get his ok
penny
-------
∂Date: 3 Jul 1980 1119-PDT
From: CSD.NII at SU-SCORE
Subject: RLL article
To: csd.greiner at SU-SCORE, rdg at SU-AI
cc: csd.nii at SU-SCORE
I've fixed the first 2-3 paragraphs of the RLL article. It is
unprotected and is in my directory at SCORE (do not use the one
at Sumex) <csd.nii>broch.rll. We are fast reaching a deadline so
could you get it back to me as soon as possible.
penny
-------
∂Date: 6 Jul 1980 1403-PDT - Nii at SUMEX-AIM - Rll write-up
To: rdg at SU-AI
cc: nii, Lenat
Russ,
I did some text editing to the version you gave me to save time.
I don't believe I changed any meanings intended in the paper. Please
look is over and see if you are satisfied--it's in <nii>broch.rll@sumex.
Meta-comments
1. Try to avoid too many parenthetical remarks. They are reserved for
statements which can be skipped over. Either something is worth
saying or it isn't. I took out most of the parentheses and made them
into regular text.
2. Unnecesary uses of "this" and "that"'s. Since the text progression
is quite logical, I replaced most of them with "the" or repeated the
references.
3. Look out for parallel constructs--avoid split infinitives.
4. Use commas, ;, and -- appropriately.
Since English is my second language, I'm not the one to criticize other's
English. However, there are some heuristics that can be learned that
might make your writing task a little easier and smoother.
penny
-------
Mailed to NI@SUMEX (& LENAT/cc) 13:03 7-July
Penny,
That document seemed good. I have (only) a few suggsted modifications;
our words do seem to be converging. One more iteration? When?
Russ
Mailed to CSD.NII@SCORE 15:41 3-July
Motivation
RLL is a tool to facilitiate the building of expert programs quickly. It
is itself an expert program, whose domain of expertise is knowledge
representation.
Task Description
The standard first step taken in building an application program (in AI)
is the design and implementation of a language which will be used
represent the knowledge this program will use. Experience has shown that
the language developed in one application is seldom adaptated for use in
other programs. The features that were useful for the original problem
become limitations elsewhere. Thus, a specialized representation language
is redesigned and reimplemented for each application -- a very time
consuming task.
RLL (Representation Language Language) is designed to reduce the time
spent building such representation languages. It is a language which
"knows" about the components of representation languages in general. It
provides the user with an extendable collection of high level operators
and constructs which he can use to describe and build components of his
target language. After the user has specified the desirable features of
the target language, RLL integrates these components into a functional,
new representation language. In other words, a user can readily (and
rapidly) design a personalized language, exactly suited to the domain and
the application task at hand.
RLL's open-ended means there were be an extendable set of possible
representational pieces. The current system can deal with pieces such as
slots, modes of inheritance, and specification for functions. Slots
conform to the definition given in the UNITS package description,
appearing earlier. (In fact, RLL borrowed much of its nomenclature, as
well as software, from this system. [Footnote: One example is a
stand-alone submodule of RLL, which implements a demand paging system.
This frees RLL from InterLisp's 256K storage limitation. (See [Smith].])
UNITs also motivated an important mode of inheritance: the one associated
with its Examples link. (This relationship corresponds to set theory
notion of "element-of".) There is nothing in UNITS which corresponds to
our use of functional specification. We are currently exploring this
domain, which helps unify many outwardly diverse concepts, such as
processes, mechanisms, and slots.
The initial RLL system is itself a very versatile representation language.
For most tasks, the user can use it as he might any other representation
language. What distinguishes RLL is that the user is not forced to follow
the constraints imposed by this particular language; instead, he can mold
his copy of RLL to accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL contains a large
library of largely independent, pre-fabricated "representational pieces".
For example, there are many (mutually incompatible) ways in which one can
associate facts with an object. One corresponds to UNIT's idea of a slot,
while another is to let each unit point the list of assertions in which it
is involves. (Consider how to represent "Fred is the Father of Mary".
Using slots, this means filling the "Father" slot of the unit Mary with
the value "Fred". In the second notation, the unit Mary would point to
the assertion "(Father Mary Fred)".) This first method, using explicit
slots, is "active" in the initial RLL system. If this proves
unsatifactory, a simple command will instruct RLL to switch to this second
system. From then on, (or, at least, until the user's next alterring
command,) this modified version of RLL will understand this different set
of instructions, and its reactions will follow this second convention.
Furthermore, RLL will automatically convert the user's existing data into
this new format.
To effectively use these varied components, RLL must "understand" what
each does, and how. This information allows RLL to mesh diverse parts
together, to form a coherent and working whole. As such, it should be
possible for the user to design a fairly arbitrary language by simply
choosing the precise amalgamation of these pieces he wishes; leaving to
RLL the responsibility, and headaches, of fitting them together.
Realizing this catalog of "chunks" will never be totally complete, RLL's
second approach towards generality are its collection of tools designed to
help the user fabricate new parts. These high-level operators can be used
to define a new component, (or type of component) or refine an existing
one.
For example, the user can define the "Parents" slot as the union of the
"Mother" and "Father" slots. That is, (the value of) the "Parents" slot
of an individual is a list consisting of (the values of) that person's
"Mother" and "Father" slots. This brief definition (Parent = Union(Mother
Father) ) is sufficient to tell RLL everything it needs to know about this
slot. RLL now knows to (automatically) invalidate the value stored for
Fred's parents if his mother remarries; and know that only some units may
have a Parents slots (viz. those which had both a Mother and Father slot
-- i.e. people).
Defining a new slot is trivial; designing a new inheritance, or new type
of format is as easy. The host of high-level operators considerably
lessens the complexity associated with constructing and integrating this
new piece.
These parts (however they were derived,) become the language the user can
use for his main task. If he later discovers limitations in this set of
facilities, he need only replace, or redesign the offending components.
RLL's collection of types of parts, and its high-level operators, make
either type of modification relatively simple. As shown above, RLL then
does the "busywork" -- such as reformatting the existing data to conform
to this new set of conventions.
Current Applications
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
An brief overview of RLL's goals can be found in [Greiner & Lenat]. This
is expanded in [Greiner], which illustrating many additional aspects of
RLL's design and implementation.
Ref:
Greiner, Russell, "A Representation Language Language", HPP Working Paper
80-9, July 1980.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", AAAI Conference, August 1980, Stanford.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, July 1980.
Received from NII 7-July (essentially final form)
RLL
Motivation
RLL is a tool to facilitiate the building of expert programs
quickly. It is itself an expert program, whose domain of expertise
is knowledge representation.
Task Description
The standard first step taken in building an application
program in AI is the design and implementation of a language that
(in which to)
represents the knowledge the program will use. Experience has shown
that the language developed in one application is seldom adaptated
for use in other programs. The features that were useful for the
original problem become limitations elsewhere. Thus, a specialized
representation language is redesigned and reimplemented for each
application -- a very time consuming task.
RLL (Representation Language Language) is designed to reduce
the time spent building such representation languages. It is a
language which "knows" about the components of representation
languages in general. It provides the user with an extendable
collection of high level operators and constructs which he can use to
describe and build components of his target language. After the user
has specified the desirable features of the target language, RLL
integrates these components into a functional, new representation
language. In other words, a user can readily and rapidly design a
personalized language, exactly suited to the domain and the
application task at hand.
RLL is an open-ended language in which the user can add pieces
of language not provided in RLL's standard repetoir. Currently RLL
can deal with pieces such as slots, modes of inheritance, and
specification of functions. Slots conform to the definition given in
the UNITS package (see page ). In fact, RLL borrowed much of its
nomenclature, as well as software, from UNITS. For example, it uses
one of UNITS main mode of inheritance, the Example link. This
inheritance relationship corresponds to set theory notion of
"element-of". However, there is nothing in UNITS which corresponds
to RLL's use of functional specification. This domain is currently
being explored, because it would help unify many outwardly diverse
concepts, such as processes, mechanisms, and slots.
The initial RLL system is itself a very versatile
representation language. For most tasks, the user can use it as he
might any other representation language. What distinguishes RLL is
that the user is not forced to follow the constraints imposed by a
particular language; instead, he can mold his copy of RLL to
accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL
contains a large library of largely independent, pre-fabricated
"representational pieces". For example, there are many (mutually
incompatible) ways in which one can associate facts with an object.
One corresponds to UNIT's idea of a slot, while another is the use of
pointer to a list or relevant assertions. For example, consider how
to represent "Fred is the Father of Mary". Using slots, "Father"
slot of the unit Mary would be filled with the value "Fred". Using
links, the unit Mary would point to the assertion "(Father Mary
Fred)". The first method, using explicit slots, is "active" in the
initial RLL system. If this proves unsatifactory, a simple command
will instruct RLL to switch to the second method. From then on,
(or, at least, until the user's next alterring command) the user
modified version of RLL will prevail. Furthermore, RLL will
automatically convert the user's existing data into the new format.
To effectively use the variety of components, RLL must
"understand" what each does, and how. This information allows RLL to
mesh diverse parts together to form a coherent and workable whole.
As such, it should be possible for the user to design a fairly
arbitrary language by simply choosing the precise amalgamation of the
pieces he needs, leaving to RLL the responsibility of fitting them
together.
Cataloging of possible components will never be totally
complete. RLL's second approach towards generality is its collection
of tools designed to help the user fabricate new parts. A set of
high-level operators are provided so that the user can define new
components or a type of components, or refine existing ones.
For example, the user can define the "Parents" slot as the
union of the "Mother" and "Father" slots. That is, the value of the
"Parents" slot of an individual is a list consisting of the values of
that person's "Mother" and "Father" slots. This brief definition,
Parent = Union(Mother Father), is sufficient to tell RLL everything it
needs to know about this slot. RLL now knows to automatically
invalidate the value stored for Fred's parents if his mother
remarries. Furthermore it knows that only some units may have a
Parents slots, i.e. those which have both a Mother and Father slots.
(Hence while each person or zebra should have parents, we should not
expect a VLSI chip to have such a slot, nor the unit representing the
class of functions.)
The language parts, however they were derived, become the
language the user can use for his task. If he later discovers
limitations in this set he need only replace or redesign the
offending components. RLL's collection of types of parts, and its
high-level operators, make modifications relatively simple. As shown
above, RLL then does the "busywork", such as reformatting the
existing data to conform to the set of new conventions.
Current Status
Although interests have been expressed in using RLL for a
variety of applications, the system has only recently become
sufficiently stable to permit others to use it. Thus far, it has
been used in two small internal tasks (an adventure game simulation
and an exploration into a more complete self-description of its
various parts using lower-level primitives,) and one still trivial
task, which dealt with oil spills (see Hayes-Roth et al.).
Sent to DBL fr NLM report - 10 April 1981
1. What else will be in this report - the unit's package?
2. What formatting system? SCRIBE?
3. Purpose of this report - to convince others of RLL's utility,
or demonstrate its abilities, or ...
In 1/2 page...
Feel free to subset this to the size you wish.
RLL
Motivation
RLL is a tool to facilitiate the building of expert programs
quickly. It is itself an expert program, whose domain of expertise
is knowledge representation.
Task Description
The standard first step taken in building an application
program in AI is the design and implementation of a language
in which to
represents the knowledge the program will use. Experience has shown
that the language developed in one application is seldom adaptated
for use in other programs -- the features that were useful for the
original problem become limitations elsewhere. Thus, a specialized
representation language is redesigned and reimplemented for each
application -- a very time consuming task.
RLL (Representation Language Language) is designed to reduce
the time spent building such representation languages. It is a
language which "knows" about the components of representation
languages in general. It provides the user with an extendable
collection of high level operators and constructs which he can use to
describe and build components of his target language. After the user
has specified the desirable features of the target language, RLL
integrates these components into a functional, new representation
language. In other words, a user can readily and rapidly design a
personalized language, exactly suited to the domain and the
application task at hand.
RLL is an open-ended language in which the user can add pieces
of language not provided in RLL's standard repetoir. Currently RLL
can deal with pieces such as slots, modes of inheritance, and
specification of functions. Slots conform to the definition given in
the UNITS package (see page ?). In fact, RLL borrowed much of its
nomenclature, as well as software, from UNITS. For example, it uses
one of UNITS main mode of inheritance, the Example link. This
inheritance relationship corresponds to set theory notion of
"element-of". However, there is nothing in UNITS which corresponds
to RLL's use of functional specification. This domain is currently
being explored, because it would help unify many outwardly diverse
concepts, such as processes, mechanisms, and slots.
The initial RLL system is itself a very versatile
representation language. For most tasks, the user can use it as he
might any other representation language. What distinguishes RLL is
that the user is not forced to follow the constraints imposed by a
particular language; instead, he can mold his copy of RLL to
accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL
contains a large library of largely independent, pre-fabricated
"representational pieces". For example, there are many (mutually
incompatible) ways in which one can associate facts with an object.
One corresponds to UNIT's idea of a slot, while another is the use of
pointer to a list or relevant assertions. For example, consider how
to represent "Fred is the Father of Mary". Using slots, "Father"
slot of the unit Mary would be filled with the value "Fred". Using
links, the unit Mary would point to the assertion "(Father Mary
Fred)". The first method, using explicit slots, is "active" in the
initial RLL system. If this proves unsatifactory, a simple command
will instruct RLL to switch to the second method. From then on,
(or, at least, until the user's next alterring command) the user
modified version of RLL will prevail. Furthermore, RLL will
automatically convert the user's existing data into the new format.
To effectively use the variety of components, RLL must
"understand" what each does, and how. This information allows RLL to
mesh diverse parts together to form a coherent and workable whole.
As such, it should be possible for the user to design a fairly
arbitrary language by simply choosing the precise amalgamation of the
pieces he needs, leaving to RLL the responsibility of fitting them
together.
Cataloging of possible components will never be totally
complete. RLL's second approach towards generality is its collection
of tools designed to help the user fabricate new parts. A set of
high-level operators are provided so that the user can define new
components or a type of components, or refine existing ones.
For example, the user can define the "Parents" slot as the
union of the "Mother" and "Father" slots. That is, the value of the
"Parents" slot of an individual is a list consisting of the values of
that person's "Mother" and "Father" slots. This brief definition,
Parent = Union(Mother Father), is sufficient to tell RLL everything it
needs to know about this slot. RLL now knows to automatically
invalidate the value stored for Fred's parents if his mother
remarries. Furthermore it knows that only some units may have a
Parents slots, i.e. those which have both a Mother and Father slots.
(Hence while each person or zebra should have parents, we should not
expect a VLSI chip to have such a slot, nor the unit representing the
class of functions.)
The language parts, however they were derived, become the
language the user can use for his task. If he later discovers
limitations in this set he need only replace or redesign the
offending components. RLL's collection of types of parts, and its
high-level operators, make modifications relatively simple. As shown
above, RLL then does the "busywork", such as reformatting the
existing data to conform to the set of new conventions.
Current Status
Although interests have been expressed in using RLL for a
variety of applications, the system has only recently become
sufficiently stable to permit others to use it.
RLL's power can be seen in the variety of tasks in which it has been employed:
an adventure game simulation
an (internal) exploration towards a more complete self-description of its
various parts using lower-level primitives,
and a complex task in which RLL assumed the role
of expert-system builder, designing a program to
handle with oil spills (see Hayes-Roth et al.).
Bibliography
@InProceedings(RLL,
Key = "Greiner",
Author = "Greiner, Russell and Lenat, Douglas B.",
Title = "A Representation Language Language",
Booktitle = "1-AAAI",
Organization = SU,
Month = AUG, Year = 1980)
@TechReport(RLLa,
Key = "Greiner",
Author = "Greiner, Russell",
Title = "RLL-1: A Representation Language Language",
Number = "HPP-80-9",
Type = WP,
Institution = CSDSU,
Month = OCT, Year = 1980)
@TechReport(RLLb,
Key = "Greiner",
Author = "Greiner, Russell and Lenat, Douglas B.", Title = "Details of RLL-1",
Number = "HPP-80-23",
Type = WP,
Institution = CSDSU,
Month = OCT, Year = 1980)
@Manual(MRS,
Key = "Genesereth",
Author = "Genesereth, Micheal, Greiner, Russell, and Smith, David",
Title = "MRS Manual",
Note = "HPP Working Paper HPP-80-24", Month = DEC, Year = 1980)
@UnPublished(ExpertSystems,
Key = "Hayes-Roth",
Author = "Hayes-Roth, Frederick, Waterman, D. A. and Lenat, Douglas B.",
Title = "Designing Expert Systems", Note = "in construction")
@Manual(Units,
Key = "Smith",
Author = "Smith, Reid G. and Friedland, Peter",
Title = "Unit Package User's Guide",
Month = DEC, Year = 1980,
Note = "(HPP-80-28, and Defence Research Establishment Atlantic # 80/L)")
Comparison to Editors
Units :: Bravo
- Each does somethings very nicely, but cannot be extended
or modified -- interpreted designed for limited (and known to be
constrained) set of tasks.
KRL :: E
- Both try for universality, and both fail for the same reason:
The interpreter cannot be changed. Although other effects can be
simulated, that's as close as one can get.
ROSIE :: IBM's Editor
- Both were designed to be learned easily, and to be inextendable.
(Rosie's aims differ slightly from Unit's:
Rosie's purpose is for each of understanding; as opposed to
representational generality -- Units avoids these linguistic issues
for the most part.)
RLL-1 :: EMACS
- Both are very general languages, designed to be modified (and to
facilitate such modifications). Both establish some initial
conventions: RLL-1 has slots, EMACS is defined exclusively for screen
displays.
MRS :: TECO
- Both are bare-bones -- just enough to get started, and to be massaged
into the form desired.
(Note EMACS can be [in fact, was] written in TECO.)
Language metaphor
Representation Languages share many similiarities with natural languages,
such as English.
Both can be used to express facts about the world,
and in both cases, such descriptions are in terms of very high level, and "natural"
units.
Both are open-ended, and extendable --
new terms can be formed from old, using various established methods.
(New words can be created by adding a prefix to an existing word.
One can infer the meaning of "verbifying", as it applies a standard
method by verbifying to the noun, "verb".
Also, a word can take on a new, or extended meaning,
by using it in a new context.)
A language is more than just a dictionary of words;
it also includes a grammar which describes
how to use words to form higher level constructs,
such as Noun Phrase, Sentence, or Story.
RLL is like a very general purpose language,
which contains a large number of words, and a very encompassing grammar.
Many users will be able to use this, sans alterations.
What distinquishes RLL from most other representational languages is its
ability to change.
It can built not only new words,
but new and different grammars as well.
Most systems impose a fairly rigid set of conventions on what they can do,
and how.
The user has no choice but to conform to these standards,
which forces some applications into awkward contortions, if it is at all possible.
It achieves this generality by describing these each of notions precisely;
representing them within RLL's own formalisms
(much like reading an text on English, written in English).
These descriptions can then be used.
A user can combine the desired features
of several distinct languages to form
a new, specialized language, suited to his particular needs and goals.
Our eventual goal is to provide an entire catalog of these language
provides the ability to shift amoung languages -- to use German's
capability to string nouns together, and
Ref:
Extensible langauge, for describing extensibilites:
Davis, Randall, "Generalized procedure calling and content-directed invocation",
SIGPLAN Noices, Vol. 12, Nol 8, August 1977, pp. 45-54
Same general ideas - of bootstrapping down & down
Sandewall, Erik, "?", IJCAI 4
Smalltalk - idea of each unit knowing what to do
Fahlman "<10% not easy to represent, and require special fixes"
[see IJCAI-79, p.282 - in article re: AMORD]
Fox (IJCAI-79 282-4) - make things as explicit as possible - and declarative
Georgeff (IJCAI-79 330) - can add semantics to MetaRules easily
[use Cogn Econ to decide what needs to be recomputed]
Laubsh (IJCAI-79 516) [W German] {ATN w/Sem Nets} put concepts into Units,
with additional facts
Leitner, Henry H (Harvard) & Micheal W Freeman(Burroughs), (IJCAI-79 525)
store with "slot" what to do
Miller, G.A., E. Galanter, and K H Pribaum "Plans & the Structure of Behaviour,
New York: Holt, Rinehard & Winston, 1960. (see IJCAI-79 555)
"Major source of new plans is old plans."
Mostow & Hayes-Roth (IJCAI-79 601) - schema for heuristic search, w/slots for facts
IJCAI-79, 617 - AKO limiting - as meaning too many things, and all imprecisely
Semantics not pure (618)
"Prespecitifed useages of attached procedures is too restrictive"
(but they still stop shrt of real soln - ie they add own (deepter) conventions)
Hayes "Defense of Logic" - refers to building an interpreter for the interpreter
[see also Stefik's HPP-80-13, appearing in ?Artificial Intelligence? 1980]
∂4 Apr 1981 1605-PST CSD.GENESERETH mrs report
To: csd.greiner
I thought you might be interested in the progress report I gave Doug.
It includes an intro paragraph that reflects my best effort at
presenting a view of the coordination between the MRS and RLL efforts.
Look out! Here it comes.
Our research in knowledge representation has largely focussed
on the problem of giving a system knowledge of itself and the ability
to control its operation and modify its structure. Two outgrowths of
this research are the Modifiable Representation System MRS and the
Representation Language Language RLL. MRS is a minimal
self-descriptive system with the ability to reason about its own
structure and behavior. RLL is intended to have more extensive
knowledge about knowledge representation and thereby facilitate the
tailoring the system for partiular applications. MRS is much smaller
than RLL and is conceived of as the core from which the more
knowledgeable RLL will eventually be built. Superficially, MRS
differs from RLL in its external language (full predicate calculus
rather than "units") and in the specific capabilities available (e.g.
general backward chaining).
MRS - A Modifiable Representation System
As a knowledge representation system in its own right, MRS is
intended for use by AI researchers in building expert systems. It
offers a repertory of commands for asserting and retrieving
information, with varying degrees of inference. Information is
entered in a predicate calculus-like language of assertions and is
stored in either a propositional network or any of a variety of
specialized data representations (e.g. property lists, alists, bit
vectors). The initial system includes a vocabulary of concepts and
facts about logic, sets, mappings, arithmetic, and procedures.
What makes MRS special among knowledge representation systems
is its ability to deal with itself in the same way that it deals with
application domains (like geology and medicine). In MRS, the basic
representation is described within the representation itself, and the
inference techniques used in reasoning about application domains can
be applied to reasoning about the system. For example, MRS might use
facts about sets and sequences to determine whether a statement is
provable, or it might use facts about directed graphs to determine
that backward chaining is the most appropriate technique to use with
forward branching search spaces.
Because of MRS's formalism and meta-level vocabulary, it's
possible for a user to ask the system questions about itself; and,
since the system has a partial self-description, it can answer many of
these questions. More importantly, the system uses its own
description in carrying out each operation. The upshot is that the
user can affect MRS's behavior simply by modifying this description.
With a few simple statements, it is possible to select a new data
structure (e.g. property lists) or enable a different inference
algorithm (e.g. a general procedure like property inheritance or backward
chaining or a domain specific procedural attachment).
Furthermore, MRS is fully modifiable, i.e. it can be
converted into any LISP program by making assertions within its own
formalism (hence the name "Modifiable Representation System"). Most
knowledge representation systems were developed in the context of
particular applications, e.g. KRL and OWL in natural language and
Units in molecular biology. The problem is that what is good for one
application is usually not perfect for another. Although most systems
offer their users a number of options, there are often undesirable
design decisions that cannot be changed. In MRS modifiability is a
design goal, which is realized by the system's self-descriptive vocabulary
and its handling of changes in its own description.
Of course, bare Lisp is also fully modifiable. One important
difference is that MRS's language is more general than Lisp's, allowing its
user to assert arbitrary facts in the predicate calculus as well as defining
procedures. Furthermore, the transformation to other knowledge representation
systems is facilitated by the knowledge about knowledge representation built
into larger systems like RLL.
State of Implementation and Use
The core of MRS is fully implemented in DEC-20 Maclisp and
Interlisp and will soon be available in Franz Lisp on the Vax and
Interlisp on the Xerox Dolphin. A separate effort is underway to
implement the system in IBM's LISP370. MRS is being used in a variety
of research projects at Stanford, incuding the DART project (automated
diagnosis of computer hardware failures) and the Intelligent Agents
project (smart interface for computer operating systems). The system
has been exported for trial use by the Hewlett-Packard Co. and the
Rand Corp.
In its initial state, MRS uses a "propositional" representation
for storing information. The representation is fully indexed and has
a flexible context mechanism. Before carrying out any operation, the
system uses depth-first backward chaining at the meta-level to figure
out how to carry out the operation. Initially, application-level
deductions also use depth-first backward chaining.
In addition to the core system, several "plug-in" modules that
substantially increase the capability of MRS have been built. The
agenda module provides the system with the ability to do breadth-first
and best-first searches in addition to the default depth-first search.
The property list module allows the user to store facts in a
frame-like property list representation instead of the propositional
representation. The demon module allows the user to write general
"if-needed" and "if-removed" methods.
Future Work
Our primary effort in the continued development of MRS is being
devoted to the costruction of useful new "plug-in" modules and a few
extensions to the inference capabilities. The issues of primary concern
at this point include an implementation of default reasoning and reasoning
with equality.
At a more theoretical level, we are expanding the system's capabilities
to reason about its own structure and behavior. Specifically, we would
like to give the user the capability to specify "invariants" that the system
will automatically enforce. We would also like to implement a module that
can reason about the structure of the knowledge in particular application
areas in order to choose or design an appropriate representation.
⊗
∂ 14 Jul 1981 2254-PDT KAPLAN at SRI-AI Origins of MRS
To: csd.lenat at SU-SCORE, csd.Smith at SU-SCORE, csd.Greiner at SU-SCORE,
csd.grinberg at SU-SCORE
cc: kaplan at SRI-AI
Dear people:
I need a quick answer on the following -
For a document that has to go via net to DARPA on this Wed., I mention MRS
and note that it was developed at MIT (by Mike, I think as part of his thesis).
If this is incorrect, i.e. if he developed it here, I would appreciate it
if one of you could let me know for the sake of accuracy.
Thanks much,
Jerry
-------
---------------
∂TO KAPLAN@Sri-Ai (CC CSD.LENAT, CSD.SMITH, CSD.GRINBERG) 11:08 15-July
Everything you always wanted to know about MRS...and more
Jerry -
Nope. As part of his thesis work, Mike wrote a predicate-calculus
like representation language named DB. On coming to Stanford, he and others
(including Doug Lenat, Dave Smith Mark Stefik and myself)
began rethinking what should go into a representation language (rl);
in particular, focussing on what sorts of things
seemed wrong or incomplete about all the existing ones.
@BEGIN(Propoganda)
The basic problem was that these rls were knflexible,
and were almost impossible to extend to match new user's needs and wants.
Our conclusion was, in retrospect, both simple and obvious:
By design, a rl is built to represent facts about various domains --
eg menengitus, or mathematical equations -- in such a way that the user
can readily reason about such information.
Why not design a rl which could represent itself?
This way the user could probe about the underlying "rl interpreter"
to help understand the language;
furthermore, this transperancy could permit the user
to modify the language as he wishes, easily.
@END(Propoganda)
The first such language designed to represent such representation language
features was RLL (for Representation Language Language).
Unfortunately need forced this to be implemented too quickly, before many
important issues were resolved. This tension (build a good, usable language
with enough self-modifiability that our needs will be met; versus design and
build the ultimate language, spending as much time now as necessary to really
understand and resolve the wealth of time-consuming issues which would otherwise
plague future work) forced Mike to splinter off, and, with much help from
Dave and some heckling/assistance from yours truly, to begin work on that
pie-in-the-sky rl, MRS -- the Modifiable Representation System
(or Mike Russ Smith, or the next version after MISS, or ...).
The most modifiable aspect of this system, to date, has been its name -- which
has now evolved to stand for Multiple Representation System.
Various potentially relevant pseudo-documents include
HP-80-8 (CORLL, the system on which both RLL and MRS are built)
HPP-80-9 (basic RLL manual)
HPP-80-23 (extended RLL appendices)
HPP-80-24 (MRS introduction)
HPP-81-6 (first Multiple RS paper)
&
"Models and Metaphors" by MRG, and Doug & my "RLL - A Rep Lan Lan" papers,
in AAAI#1.
That answer your question?
Russ
∂15-Jul-81 1122 David E. Smith <CSD.SMITH at SU-SCORE> Re: Everything you always wanted to know about MRS...and more
To: RDG at SU-AI
cc: kaplan at SU-SCORE
I'd say that DB/ANALOG had considerably more impact on MRS than did RLL. -- de2
-------
∂15-Jul-81 1134 KAPLAN at SRI-AI Re: Everything you always wanted to know about MRS...and more
To: RDG at SU-AI
cc: csd.lenat at SU-SCORE, csd.smith at SU-SCORE, csd.grinberg at SU-SCORE
Thanks for the info, I have revised and sent the draft to reflect the
correct story.
Sorry for the confusion,
Jerry
-------
[RLL Section of BES Book - Original - sent to DBL, thence to Waterman]
(ca 10 July 1981)
RLL
2.2.8.1. Motivation
Expert systems are based on the observation that many problems
(such as medical diagnosis, or legal reasoning) are very
difficult. Due to both the sheer number of the constinuent
parts (eg court cases, or known laboratory techniques),
and to the intricacies of their interactions,
computers seem better able to cope with such tasks than humans.
So expert systems evolved, to help (human) domain expert manage
both the bulk and complexities associated with these chores.
Experience with such expert systems has lead to an interesting,
although usually overlooked, insight:
the programs which help design and implement
expert systems are themselves complex beasts.
Indeed, the domain of programming exhibits
the same types of complexities
that prompted computer scientists to build expert systems in the first place.
For example, one can use partial specification equally well
in any planning task, whether the domain be
designing molecular genetics experiments or constructing computer programs.
NEEDS WORK!!
2.2.8.2. Overview of RLL
This realization triggered RLL's development.
It is, first, a collection of tools which help
the KE to construct, use, and adapt an Expert System program.
In addition, it is itself a bona-fide expert system --
knowledgable in facts about programming in general, and its own subroutines
in particular.
This competency permits RLL to "understand" its internal inference procedures,
and provides the user with a tool for modifying these programs
to meet his specifications (rather than vice versa).
<<<< Begin >>>> ****** Is this needed ****** <<<< Begin >>>>
Every ES must have a "competence model" of its domain.
It is this knowledge which allows
that system to reason about the facts of its field.
(For exmple, MYCIN's "knowledge" of the facts about meningitus
is used to answer questions about the nature, cause
and effects of this disease.)
On the other hand, although MYCIN uses a backward chaining
inference engine to perform its deductions,
its "knowledge" of this process is limited to a weak "performance model"
-- MYCIN could not tell the user why it chose this particular control structure,
or indicate how exactly it works,
except by example.
While the domain of any Expert System Building program (ESBp) is
programming, few have a real "competence model" of this domain --
i.e. few have any "deep understanding" of the
programming constructs of the target programs they are building.
(EG while AGE can construct a Blackboard based reasoning system,
it cannot reason about such a system -- to answer questions about,
for example, its effeciencies; nor can it modify that BB model, to
handle, for example, a different type of rule.)
Like the other ESBps, the RLL system begins with a store of such constructs.
This class includes a non-trivial collection of types of slots, control
mech↓nisms, and inheritance schemes.
Each of these units is described in RLL's formalisms.
This specification is sufficiently "deep" that arbitrary ensembles
of these parts can be combined;
and it is this collection of parts which
forms the user's particular representation language.
However RLL was designed with the realization
that no single set of starting primitives could possibly satisfy
all of the users all of the time.
Hence RLL goes on to provide a number of tools,
which the user can use in constructing his own pieces --
for example, the user can create a new type of slot or inheritance procedure
by performing a simple modification to a "close" existing one.
<<<< omit this
RLL's competence model is essential at this point.
Many indirect ramifications may arise when
such a modification is performed, and the overall system must
be able to find all parts of the systems which may be affected by this change,
and update these pieces appropriately.
RLL's collection of facts about the field of programming
may be necessary ...
omit this >>>>
<<<< End >>>> ****** Is this needed ****** <<<< End >>>>
This permits it to "understand" what it is doing as it constructs the
target Expert System, using a reasoning process not unlike Tierasias's;
only more elaborate and encompassing. (Ie Tierasias had only a rudimentary
understanding of certain forms, within a small set of molds.
RLL can actually create new molds as necessary.)
RLL can create new modes of inference, with the same types of steps
a program like CASNET would use to incorporate a new
fact about a patient, or a new type of disease.
The next two subsections will indicate how RLL's flexibility aided us
in designing, building and updating the Oil Spill System we built, OSS.
Section 2.2.8.3 outlines the approach we followed in contructing OSS.
Notice that RLL allowed the specifics of the problem to guide the
nature and implementation of the final system
-- rather than force OSS into some particular formalism,
we designers were given great latitude in determining what
control structures to use, as well as the form of the data.
This permitted the system builders to make
effectively all of the important design decisions,
rather than be limited by the particular options which happened
to be included in the ESBp.
One of RLL's forte is its adaptability -- this carries over to the
programs it is used to construct.
Section 2.2.8.4, in listing RLL's major points, shows how easy
it was to modify OSS, both as we were building it,
and as we revised/upgraded it, after its "completion".
We next show some of RLL's main weaknesses,
both those inherent to this type of system, and those which
are only present in the current implementation.
The conclusion answers a few remaining question - such as RLL's historical
genesis, and how problems of efficiency are solved.
<<<<BELOW: THIS PART WAS EXCISED - it will be included in Rand report>>>>
2.2.8.3. Approach to Oil Spill Problem
We outline below the approach we followed in building OSS, a program
for handling (a subset of the problems associated with) inland
chemical spills.
Step 0: Determine what problem was to be solved.
(Note this step is unusual for KE tasks in general.
The particular task is usually fairly well defined
before the programme has even been contemplated.)
We decided OSS would concentrate on
solving the backtrack-to-source problem; but would include
a wide range of facts pertaining to this overall inland chemical spill situation.
Step 1: Decide what data should be represented.
We encoded as units facts ranging from very general statements about spills,
down to what pipe connected to which manhole in this installation.
Note that we had NOT decided yet how to represent these facts -- ie into
what set of hierarchies, and with what properties explicitly stored --
This is delayed until Step 3, after the basic control algorithm had been proposed.
(As AA texts will show, this is a good practice, as it avoids a premature
commitment to an awkward representation.
Note further that this is only possible in a system which
permits more than one structure for the data,
and more than one mode of inteference, such as RLL.)
In addition to the standard collections of individuals (eg Pipe#34), class of
such objects (eg AnyPipe, which refers to the set of all pipes) and the features
associated with such "set theoritical" objects,
we realized we would have to represent events -- general objects
which could be gradually refined. An example should help drive home this idea:
We may want to say general things about oil spilling into a body of water --
for example, that it causes a sheen.
We would prefer to place all such facts on one place,
eg the OilSpillingIntoWater unit, and know that every more specialized case,
eg oil spilling into the stream, will inherit such facts. (That is, that oil
will cause a sheen in the stream.)
So we would want the OilSpillingIntoStream unit to inherit everything
found in the more general OilSpillingIntoWater unit.
We could go on to describe
facts about OilFromPipe93SpillingIntoWOC,
in turn, can be further restricted into
MachineOilFromPipe93SpillingIntoWOCAfterOutFall93, (which can be
restricted to DayOldMachineOil#2FromPipe93'sFirstOutletSpillingIntoWOC-
AfterOutFall93onAug23.
Of course,
these units are not simply produced
arbitrarily -- only when you have something to say about such an
event will you create a gestalt to hold this information. If the fact
is general, it should go on a general event unit, which enables its
descendants to inherit these facts.
Anyway, the mechanism for handling this type of inheritance is distinct from
the more standard ElementOf or SubsetOf relations; and in RLL one can state
just what is expected of this relation precisely and explicitly.
Step 2: Decide on the Control/Inference Algorithms
To properly perform this step it is essential to analyze the characteristics
of the eventual system.
For example, the complete OSS is expected to perform a variety of different tasks
-- from determining the type of the spill to performing various
<remediation tasks>, such as notifying the authorities.
Another important characteristic of this job is the timeliness and ordering
of these tasks --
the importance of recording the name of first witness dwindles when
compared with telling him not to breathe the toxic fumes.
Hence determining the toxicity of the vapors
should be of tantamont importance,
especially when the leak might be near people.
A well structured agenda seemed ideally suited to these specifications.
(An additional plus was that
even this still immature RLL system already had this program construct.)
The agenda contains an ordered list of tasks, which are processed sequentially.
Each task is designed to performs a particular bitesize job.
For example, the goal of one task may be to determine the values
of some parameters, (e.g. the task MatType attempted to deduce
the type of material which had spilt,)
another may add other tasks to this agenda,
(for example, the task in charge of effecting the Countermeasures added
several new tasks to the agenda - one to notify the authorities, another to ...)
and a third type would print out instructions/requests to the user
(eg "go to Manhole #34 and tell me if you see oil").
Other kinds of tasks (which were not necessary for this particular domain)
could create a new concept,
or decide to rearrange the tasks on the current agenda,
in recognition of some new fact.
Executing a task meant collecting relevant rules, then ordering and firing
this list in sequence.
There are many types of rules, each charged with (attempting to) achieve a
different type of goal.
(In this sense they are similar to tasks, only in a smaller scale.)
Some rules employ a known technique (algorithm) to evaluate
the value of some attribute.
(For example, determining the toxicity of a given material by looking
it up in a table.)
Others may decide to add additional rules to this rule-set,
or propose adding a particular new task to the agenda.
Still others may suggest that the current task (in which this rules occurs)
be suspended, to await necessary new data.
(Note the flow of command is quite structured.
Each rule, task or agenda* can only effect its immediate surroundings.
More global changes are performing to sending messages to its overlord,
proposing this alteration.)
* Footnote: RLL (EURISKO) is capable of dealing with several agendae --
swapping among them as need arises.
This facility was one of many RLL features which were not needed
for this job.
We will discuss below how the rules themselves will be represented,
along with the benefits of this format.
<<<<ABOVE: THIS PART WAS EXCISED - it will be included in Rand report>>>>
Step 3: Decide how to represent the facts/procedures/rules...
3a) Once the overall inference mechanism has been determined
3b) Decide how to represent the control mechanism
Before we can describe the sort of decisions which are made at this
point, a brief digression is necessary -- to explain RLL's basic philosophy,
and how this permits us to decide on the representation to use.
(We'll tell you when the digression is over.)
RLL is based on the "To every thing, a unit" philosophy.
This uniform representation system extends beyond just encoding the
domain knowledge -- here facts about types of oil and connectivity of pipes.
Units are used to store facts (as well as the executable code) associated
with the representation itself -- such as the descriptions for each type of
slot, or the procedure used to process a given task.
*--------*--------*--------*--------*
M6-3
Isa: (AnyManhole)
FeedsInto: (M6-2)
M6-2
Isa: (AnyManhole)
FeedsFrom: (M6-3)
AnyManhole
Examples: (M6-2, M6-3, ...)
Description: This represents the class of all manholes.
*--------*--------*--------*--------*
RLL is (unfortunately) committed to using a semantic net based representation,
based on gesalts called "units",
whose attributes are defined with a set of property-value pairs*)
[* footnote: these properties are called Slots, for historical reasons.]
Within this minor constraint, RLL does provide great flexibility.
We show below that the information relevant to each type of slot is stored in
a unit.
The unit below shows that:
The value of x:FeedsInto must be a list of manholes, the only x for which
x:FeedsInto is defined is a manhole, and that if x:FeedsInto = y, then
y:FeedsFrom = x (i.e. FeedsInto:Inverse = FeedsFrom).
*--------*--------*--------*--------*
FeedsInto
Isa: (AnySlot)
Description: This slot maps from manholes to manholes.
Inverse: FeedsFrom
HighLevelDefn: (Composition OtherEnd ConnectedPipes)
Domain: Unit representing a manhole.
Format: SingleElements
Datatype: Unit repesenting a manhole.
ToCompute: (λ (u) [Find the pipe, P, to which this manhole connects.
See which pipe, p', to which this P is connected.
Return the manhole m, which is connected to
pipe p'.]
Note - the ToCompute of a slot indicates how to deduce its value -- i.e.
S:ToCompute is a function, F, whose value, (F u), is the value to fill
u:S.
*--------*--------*--------*--------*
It is important to realize that those facts shown above are not JUST a description
of the FeedsInto type of slot -- it really is used to define this slot.
If any of those slots were ever changed, the way this slot behaves would
be affected. For example, declaring FeedsInto:Format is a SetOfElements would
cause RLL to redefine each FeedsInto:ToCompute to return a singleton list
rather than a single atom (corresponding to that manhole,)
and to (retroactively) fix up each value of u:FeedsInto.
[If that value was empty, it would remain empty. Otherwise the single value
v would be changed into the list (v).]
Similarly, each data structure -- each rule, task, and agenda --
is stored as a unit.
This permits (facilitates) the data to dynamically altered during
the course of the computation, or through user input.
(IE one can use the same procedures to add in a new rule that are used
to add a new pipe, or new type of slot.)
Even the procedures of this system
-- the parts of the control structure outlined above --
are encoded in units.
As with parts of the repesentation, these facts are actually used as the
system is run.
For brevity, we will only address one of these chunks -- the rules.
Each rule has a number of obvious attributes.
First, the rule has to store the actual code which is to be executed.
The user is spared the task of enterring the
actual LISP expression to be run;
instead he provides a higher level specification of what this rule
is to do, and RLL "expands" this definition into that code.
There are several major advantages to
providing both high and low forms of a rule specification.
In addition to facilitating the creation of a new rules,
this higher level makes the nature of the rule easier to understand
and reason about, for both the user and RLL itself.
*--------*--------*--------*--------*
Rule#332
Isa: (AnyRule)
Description: Tell the user to hold his breath if the chemical is toxic.
IfPotentallyRelevant: (APPLY Toxic Chemical)
IfTrulyRelevant: (APPLY NearbyUser ChemicalHasSeepedTo)
ThenTellUser: "Do not breath this chemical!!"
ThenAddToAgenda: EmergencyProcedures
Priority: High
OnTask: ImminentDanger
ImminentDanger
Description: This task tries to find if the current situation is
dangerous; and if so, suggest solutions/fixes/alternatives.
Isa: (AnyTask)
RuleList: (Rule#332, ...)
EmergencyProcedures
Description: This task is called iff the current situation is dangerous;
and issues many quick-and-dirty orders.
Isa: (AnyTask)
RuleList: (Rule#981, ...)
-Note the rule above is what the user would type,
and not the actual running code which RLL would compute as needed.
*--------*--------*--------*--------*
Notice the code for this rule is scattered about, stored in several distinct
slots.
This permits different parts to be executed independently --
for example, allowing the quick IfPotentially check to run to all of wide
class of rules; and then running the more expensive IfTrulyRelevant part
only on that small subset which passed.
The THEN parts are also split up. Once the IF-parts have all passed, each
of those is, in sequence run.
Of course what we described above was the way the rule was evaluator, "by default"
- read that, unless the user has something else in mind.
Recall any user can readily modify that rule-evaluating procedure as well.
So, for example, the user may decide instead to execute the code implied by
the IfWorkingOnTask slot of a rule, or IfTodayIs, or any other set of slots.
(rather than the current IfPotentiallyRelevant and IfTrulyRelevant slots
now used.) Or he may decide to compose a single IF-Part, which ANDs together
all of these, and runs these at once. Similarly he may want the THEN parts
executed in a different order; or may have decided to only run those THEN parts
for which he has sufficient resources.
Note that this could not be done if each rule was simply a single piece
of compiled code.
We claimed above that it was easy to change the rule interpreter.
This is because that block of code is itself an RLL unit.
Like the rules, it is decomposed into nice sized chunks, which can
be independently modified.
One such hook is a list of slotnames which constitute
the IF part of a rule, together with a description of when that code should
be executed. Details of this, and other specifications, can be found in [Greiner].
Before leaving this rule description, there are several other
"declarative" facts stored in each rule.
One important slot is the average CPU time this rule has spent, for executing
its IF parts and THEN parts, respectively. This can be used for various
meta-reasoning tasks -- such as deciding whether to even consider this rule
in the future (ie did its bang justify its bucks).
Another field is the rule's author - be in human or another rule.
This can help decide who to credit/blame for good/bad rules; and this data
can help the overall system to improve its performance by relying more and more
on capable (that is, successful) rule writers.
Finally, the user himself can store any other type of information he wants --
these are just things which we feel may be useful types of statistics.
Similar mechanisms exist for processing agendae, or tasks, or other control
regimes. (For example a black board architecture, for other types of tasks.)
There are corresponding varieties of data structures - ways of extending tasks,
for instance.
Of course various inference schemes - most importantly an inheritance hierarchy -
is used to simplify data entry. A new rule structure can be entered by
copying the existing prototype, and changing those entries which are inappropriate.
Most properties are simply inherited from more general ideas -- here from
RLL's facts about rules in general. (In fact, for pedagogic reasons, we might
not even tell the novice user about RLL's extendability; or at least not until
he begins to complain about how awkward it is to encode this or that fact.
Until that time, he need never know anything more that a "behaviour description"
of the rule interpreter -- which is all he would ever know about the corresponding
evaluator in most other ESs.)
*-*-*-* Back to the plot *-*-*-*
The above description of rules, etc., was only to illustrate the type of decisions
one can make at this level. Here one can determine what sorts of executable slots
a rule can have, and what such slots "mean" -- that is, when that code should
be executed.
This is a further specification of the underlying type of algorithm
(here an Ordered Agenda Execution,) and is done as a seperate step, after
the overall idea had been determined.
Step 4: Run the system, and modify what has to be modified.
While (4a) "Test the neo-natal system" is standard to ESBps,
(4b) "Change those parts which should be changed" is not.
In RLL, all of the executable code is made explicit, and the user
is permitted to modify it to suit his design.
We saw in Step 3 some of tools RLL provides for such adaptations --
a high level specification language, and appropriate chunking of the knowledge.
There it was used for construction of parts -- but it can also be exploited
for retro-actively modifying existing parts.
As we saw, RLL's structure makes
changing the code as easy as altering any domain data
-- as the "program" used to test a rule's pre-condition is in the same format
as data about Oil#31, or any other bit of data used.
There are many levels of modifications permitted to data stored in RLL.
The simplest type of alteration pertains to domain data -- deciding that
Pipe#406 really joined Pipe#317, rather than Pipe#316 as you had thought.
This sort of fix could be performed in any ES.
But now suppose you realized that pipes could really join many pipes, rather
than just one. This would be difficult to say in many languages --
indeed the only solution in most might require throwing away that Connected
link and defining a totally new ConnectedS link. Even then all of the existing
data would have to be transfered, regrettably by hand.
Not so in RLL. As the example given above shows, this could be done automatically.
The actual control mechanism could be altered as well. In the initial simple
OSS system we simply pre-assigned a set of rules to each task.
Another approach would be to require each task to first gather those rules
it might need, and then fire those. This required changing the basic task
processor, by simply putting in that "initialization" proceudure.
(Fortunately this was simply adding in a pre-existing known routine.)
Nonetheless, this fix was quite easy to make.
The initial implementation wasn't worried about time or space problems.
Each task ran until it thought it was done, and then the task which was
next in importance started up. We then decided this was sub-optimal -- as
some tasks might become gradually less important, to where some sub-part of
another task would be more relevant.
So we changed the task-interpreter again, to suspend tasks after some length
of time. Another fix could (but wasn't made) in the Agenda-processor to
only consider tasks which could be achieved in x units of time.
(This too would be easy - by adjusting the weight function, used to evaluator
the worth of each task. The ordering of the agenda is determined by this measure.)
There were several other things which we considered but decided not to change:
One was to use more general types of rules -- where each rule could dictate
how to fire it, in each given situation -- eg when gathering rules, or testing
preconditions, or .... This would permit IfThenElse types of rules,
or even "rules" which were simply a procedure
-- perhaps a call to a Fortran program.
2.2.8.4. RLL's Strengths and Weaknesses
WINS
Throughout this report we have pushed RLL's strengths -- basically these
all derive from RLL's "competence model" of programming in general,
and of the data structures and algorithms it uses in particular.
Not mentioned was its capability to ignore InterLisp's 256K storage
maximum, using a demand paging algorithm [CORLL], and its basic Lisp support --
providing advantages like spelling correction, and inline editors.
From the above descriptions imply that RLL is actually "executing" high level
specifications of various control algorithms.
Were this true, RLL would have sacraficed any hope for speed and
(time-)efficiency for the sake of flexibility.
That is NOT the case. While RLL does preserve these high level descriptions
definitions, it ALSO stores what these forms "compile" into -- and it
is that latter body of code which is actually run.
Much of RLL boot-strapping code is devoted to preserving such interrelationships --
so that any change to a high level form marks the (formerly-)corresponding
executable code as invalid. On demand (that is, the next time that code
is needed,) RLL will expand that new high level definition into runnable
code; and store these low level forms so they will accessed speedily
next time the code is needed.
Returning now to the question of efficiency, we see that RLL's code
can be arbitrarily fast.
Rather than "interpret" the high level descriptions, RLL first "compiles"
these into efficient forms, and runs this faster code.
This costs only a constant overhead -- for the one time charge of
expanding that terse description. From there on the code can be
arbitrarily efficient.
Basically RLL has paid for its flexibility in terms of space -- to maintain
the different versions of the code -- and not in time.
More details on how these multiple versions are maintained, used and cached
can be found in [CogEco].
LOSSES
RLL's biggest problem, at this stage of its development, is its immaturity.
By design, it will continuously incorporate new facts about control structures,
forms of representation and modes of inheritance.
However, OSS was built way too early in this ongoing design process.
For example, RLL had never encountered a Solvable Problem before --
all of its previous work had been directed towards AM-like searches --
things which never terminal with a final verdict (ie RLL knew about tasks
like "Find examples of primes", but not about things like "What is the source
of the spill").
Another big weakness, which also stemmed from its youth, was its lack of
a user front end. A trivial example involves the way we were forced to
enter the code -- everything was in a LISPy (GetValue 'Material
'Name), rather than a nicer "Material's name".
At a deeper level, RLL did not yet have any notion of context --
this forced us designers to explicitly type (continuing the above example)
"Material name" rather than the (sufficient) "name".
A good front end could have aided in the design of this system, by suggesting
appropriate data structures and algorithms as we went. This too was missing.
The final major fault seems almost paradoxical:
it was RLL's total adaptability.
Too much freedom, we found, forced us to spend considerable time
deciding which really was the best.
This time, of course, was not ill-spent; the final OSS is certainly
better than any comparable system which forced out hand at each step,
molding out final code to match its limited set of components.
However, any such external constaints would have
narrowed down our search, and helped us finish the system in the
four days we were allotted.
Once again this type of problem could have been alleviated in a more
mature system, which included a competent front end which would have
served as "gentle guide" during this building process.
2.2.8.5. Conclusion
We will conclude win a perspective of RLL -- in terms of its past, its
current status, and our long term plans.
A year ago, RLL began as a two week project to build a representation language on
which the EURISKO system would be built.
We soon realized many non-trivial research issues had to be addressed before
such a general, "self-encoding" language could be constructed.
(We eventually abandoned the quest for this ultimate language, satisfying
ourselves with the generality which was possible within a limited set of
constraints. The more theoritical aspects of this rll work was taken up
by other members of the HPP community; and their next step is described in
[MRS].)
The current system plays a necessary boot-strapping role -- certain parts
of the system must be present, as these are used to fill in other parts.
(For example, the code which is used to expand high level definitions must
be present -- or at least enough of it to generate the rest of it.)
The initial control mechanism was the one needed for the EURISKO work --
which was an Agenda structure. OSS used a minor variant of this system.
In the long run we will actually build RLL into the MRS system -- viewing
each of the seperate decomposable parts of this systems as an MRS module,
which can be individually or collectively plugged in (ie activated).
Using MRS as a Lingua Franca, RLL will be able to absorb a large corpus
of knowledge and examples from a multitude of users -- the MRS community.
Each of these other modules will hold facts about a particular domain, or
part of that domain -- eg Medical tutoring, VLSI design, or planning experiments
in the field of Genetics.
For its part,
These RLL-based MRS modules will store facts about certain types of representations,
together with their major applications.
Important in this list will be expertise about expertise.
It is this knowledge which will enable RLL to fashion new ESs with greater
efficient and accuracy.
BOTTOM LINE
While other ESBp systems have proven expedient for tackling particular problems
in particular domains, we feel such systems will always be limited
in the scope of problems they can solve.
We feel this problem is intrinsic to such programs, at least until
they, like the human programmers they are trying to emulate,
are capable of a crude understanding the code they are composing at something
more than the superficial level now attains.
RLL was written with the goal of attaining this necessary
undertanding.
[My version, after fix up (after Don, after DBL,from me)]
∂ Monday, 6 Jul 1981 15:33-PDT Re: tools chap
To: CSD.LENAT at SU-SCORE
Cc: don at RAND-UNIX
In-reply-to: Your message of 25 Jun 1981 1502-PDT.
From: don at RAND-UNIX
Doug: I reorganized your section for you -- the material I pulled out will
go into the Rand Report. Naturally, you will have to modify the content of
the chapter yourself. It still needs a bit of work to smooth it out and
change the emphasis from a description of the SPILL program to a
description of RLL using the SPILL problem to illustrate important points.
I need your revised chapter as soon as possible (yesterday) so I can send
the publishers we are considering the draft of the book they have been so
patiently awaiting. We will not send them anything on the metacognition
section since (I assume) it won't be ready for some time.
I put a copy of the tools chapter draft into the mail for you today. It
may help to see how the other people have organized their sections of
the chapter.
Regards,
Don
------------------------------------
(16 July 1981)
2.4.1 RLL
Expert systems (ESs) are based on the observation that many problems
(such as medical diagnosis, or legal reasoning) are very
difficult. Due to both the sheer number of the constinuent
parts (eg court cases, or known laboratory techniques),
and to the intricacies of their interactions,
computers seem better able to cope with such tasks than humans.
So expert systems evolved, to help (human) domain expert manage
both the bulk and complexities associated with these chores.
Experience with such expert systems has lead to an interesting,
although usually overlooked, insight:
the programs which help design and implement
expert systems are themselves complex beasts.
Indeed, the domain of programming exhibits
the same types of complexities
that prompted computer scientists to build expert systems in the first place.
For example, one can use partial specification equally well
in any planning task, whether the domain be
designing molecular genetics experiments or constructing computer programs.
This realization triggered RLL's development.
It is, first, a collection of tools which help
the KE to construct, use, and adapt an Expert System program.
In addition, it is itself a bona-fide expert system --
knowledgable in facts about programming in general, and its own subroutines
in particular.
This competency permits RLL to "understand" its internal inference procedures,
and provides the user with a tool for modifying these programs
to meet his specifications (rather than vice versa).
This section will quickly overview this RLL system, taking examples
from our experience coding up OSS -- the Oil Spill System.
As a secondary goal (in addition to describing RLL,) we hope to
express our conviction that (i) a self-encoded system -- one which can
begin to "understand" its own operations to where it can assist in
performing such modifications --
is immensely worthwhile, especially in the long run;
and (ii) that the price of this capability is really not that great.
!2.4.1.1 Overview of RLL
Every ES must have some "competence" of its domain.
It is this knowledge which allows
that system to reason about the facts of its field.
(For example, MYCIN's "knowledge" of the facts about meningitus
is used to diagnose patients who have this disease, and
to propose medications.)
On the other hand, although MYCIN uses a backward chaining
inference engine to perform its deductions,
its "knowledge" of this process is limited to a weak "performance model"
-- MYCIN could not tell the user why it chose this particular control structure,
or indicate how exactly it works,
(except by example).
<<<Doug - this paragraph must be changed for political reasons>>>
While the domain of any Expert System Building program (ESBp) is
programming, few have a real "competence model" of this domain --
i.e. few have any "deep understanding" of the
programming constructs of the target programs they are building.
(EG while AGE can construct a Blackboard based reasoning system,
it cannot reason about such a system.
For example, it cannot answer questions about its efficiencies;
nor can it modify its basic Blackboard model to handle,
for example, a different type of rule.)
Like the other ESBps, the RLL system begins with a store of such constructs.
This class includes a non-trivial collection of types of slots,
(such as Isa or RangeType,)
control mechanisms,
(eg Backward chainers and agenda processes,)
and inheritance schemes
(for example, the ExampleOf relation).
Each of these units is described in RLL's formalisms.
This specification is sufficiently "deep" that arbitrary ensembles
of these parts can be combined;
and it is this collection of parts which
forms the particular representation language KE will use.
However RLL was designed with the realization
that no single set of starting primitives could possibly satisfy
all of the users all of the time.
RLL therefore include provide a number of tools,
which the user can use in constructing his own pieces.
For example, the user can easily create a new type of slot
or inheritance procedure.
(One standard "creation" method involves copying
a "close" existing chunk, then modifying that copy.)
RLL's competence model of programming is essential at this point.
There are many indirect ramifications which arise when,
say, a new laboratory technique is added to Molgen's data base;
similarly there are a host of actions which must be taken
when some part of the underlying representation is changed.
Just as Molgen's code is responsible for propogating the effects of this
new data, so the overall RLL system will
find the parts of the systems which may be affected by this change,
and update these pieces appropriately.
RLL allows the specifics of a problem to guide the
nature and implementation of the user's final ES
-- rather than force the system into some particular formalism.
The KEs are given great latitude in determining what
control structures to use, as well as the form of the data.
This permits the system builders to make
effectively all of the important design decisions,
rather than be limited by the particular options which happened
to be included in the ESBp.
So much for the overview and motivation.
The rest of this RLL section attempts to flesh out this skeletal description.
Subsection 2.4.1.2 explains how facts are represented in RLL ,
and shows how this structure is adequate to handle knowledge
about both the particular domain (eg Oil Spills) and RLL internals themselves
(eg facts about slots or control mechanisms).
This section includes a concrete example, using RLL's management of rules
to show first how the facts are stored, and then
how various type of
modifications can be done -- ie how RLL has attained this degree of flexibility.
Section 2.4.1.3 describes the control structure used for this partcular OSS
application, in a fair amount of detail.
This sections also explains how RLL can simultaneously be explicit and perspecious,
and yet maintain a high level of efficiency.
The last two concluding sections describe first, how RLL fits into the world,
and then overviews what still has to be done.
!2.4.1.2 Knowledge Representation in RLL
RLL is based on the "To every thing, a unit" philosophy.
This uniform representation system extends beyond just encoding the
domain knowledge -- here facts about types of oil and connectivity of pipes.
Units are used to store facts (as well as the executable code) associated
with the representation itself -- such as the descriptions for each type of
slot, or the procedure used to process a given task.
*--------*--------*--------*--------*
M6-3
Isa: (AnyManhole)
FeedsInto: (M6-2)
M6-2
Isa: (AnyManhole)
FeedsFrom: (M6-3)
AnyManhole
Isa: (AnyClassOfObjects)
Examples: (M6-2, M6-3, ...)
Description: This represents the class of all manholes.
*--------*--------*--------*--------*
RLL is (unfortunately) committed to using a semantic net based representation,
based on gesalts called "units",
whose attributes are defined with a set of property-value pairs*)
We will show below the great flexibility RLL does provide,
within this minor constraint.
[* footnote: these properties are called Slots, for historical reasons.
We use the notation Unit:Slot to refer to the value of the Slot slot of
the unit Unit.]
The above units refer to specific objects which exist in the real world --
eg M6-3 represents manhole #2 on ? #6 --
or classes of such objects --
as AnyManhole encodes facts about the set of all manholes.
Other types of units which refer to things like events, which,
unlike individuals, can have varying degrees of generality.
An example should help illustrate this point:
We may want to say general things about oil spilling into a body of water --
eg, that it causes a sheen.
Ideally all such facts should be stored in one place,
say the OilSpillingIntoWater unit,
in such a manner that every more specialized case,
will inherit these facts.
Ie we would expect RLL to conclude
that oil spilling into a stream will cause a sheen in that stream
once it knows that
OilSpillingIntoStream is a specialization of
OilSpillingIntoWater.
We could go on to describe
facts about OilFromPipe93SpillingIntoWOC,
in turn, can be further restricted into
MachineOilFromPipe93SpillingIntoWOCAfterOutFall93, (which can be
restricted to DayOldMachineOil#2FromPipe93'sFirstOutletSpillingIntoWOC-
AfterOutFall93onAug23.)
It is important to realize that these units are not simply produced
arbitrarily --
such event units are created only when there is some
pertanent fact to preserve about the event.
When the fact
is general, it should go on a general event unit, which enables its
descendants to inherit these facts.
Anyway, the mechanism for handling this type of inheritance is distinct from
the more standard ElementOf or SubsetOf relations; and should be treated as such.
RLL insures this seperation by allocating
different units to store facts about each type of inheritance.
Various properties of these inheritance-defining units
indicate how to initialize a new unit
(as stating that Pipe#33 is an Example of AnyPipe should be handled quite
differently from the statement that OilSpillingIntoStream is a
Specialization of OilSpillingIntoWater), or how the values of some slot
may be altered, to maintain this particular inheritance relation.
(eg the SubstanceSpilt of any Specialization, S, of OilSpillingIntoWater must be
some refinement of Oil, whereas S:TimeOfSpill can be arbitrary.
Analogously Pipe#33 can have slots like Length or TimeOfCreation, but not
things like Father or RangeType.)
Exactly how such data is encoded is far too detailed (and irrelevant) for
this report; the important fact is that such facts can be
stated precisely and explicitly in RLL.
Furthermore, such facts can be altered by the user, if his task demands it.
Indeed, the user can even create new "representational pieces":
As none of RLL's prior tasks had needed this Specialization inheritance,
our starting system did not have this particular feature.
We therefore had to design and build
this totally new mechanism, and incorporate it into RLL,
an all but impossible for most ESBps.
Thanks to tools RLL provided, this chore was quite easy.
Note that this feature is now a part of RLL --
subsequent users can now use this type of inheritance,
as easily as any of the other ones RLL "always" provided.
[*fnnote: Returning to a point made in the introduction,
we envision RLL will be constantly growing -- largely through additions
provided by its users. Eventually this growth, we hope, will slow down;
once a "critical mass" of useful features have been built. Needless to say,
this has not yet occurred.]
Slots are another type of representational piece.
As with inheritance modes,
the information relevant to each type of slot is stored in a unit.
The unit below shows that:
The value of x:FeedsInto must be a list of manholes, the only x for which
x:FeedsInto is defined is a manhole, and that if x:FeedsInto = y, then
y:FeedsFrom = x (i.e. FeedsInto:Inverse = FeedsFrom).
*--------*--------*--------*--------*
FeedsInto
Isa: (AnySlot)
Description: This slot maps from manholes to manholes.
Inverse: FeedsFrom
HighLevelDefn: (Composition OtherEnd ConnectedPipes)
Domain: Unit representing a manhole.
Format: SingleElements
Datatype: Unit representing a manhole.
ToCompute: (λ (u) [Find the pipe, P, to which this manhole connects.
See which pipe, p', to which this P is connected.
Return the manhole m, which is connected to
pipe p'.]
Note - the ToCompute of a slot indicates how to deduce its value -- i.e.
S:ToCompute is a function, F, whose value, (F u), is the value to fill
u:S.
*--------*--------*--------*--------*
It is important to realize that those facts shown above are not JUST a description
of the FeedsInto type of slot -- it really is used to define this slot.
If any of those slots were ever changed, the way this slot behaves would
be affected. For example, resetting FeedsInto:Format to be SetOfElements
(rather than SingleElement) would
cause RLL to redefine FeedsInto:ToCompute to return a singleton list
rather than a single atom (corresponding to that manhole,)
and to (retroactively) fix up each value of u:FeedsInto.
[If that value was empty, it would remain empty. Otherwise the single value
v would be changed into the list (v).]
Similarly, each data structure -- each rule, task, and agenda --
is stored as a unit.
This permits the data to dynamically altered during
the course of the computation, or through user input.
(IE one uses the same procedures to add in a new unit, independent
of whether that unit represents a new rule,
a new pipe, or new type of slot.)
Even the procedures of this system are encoded in units --
including especially the parts of the control structure outlined below.
As with parts of the repesentation, these facts are actually used as the
system is run.
For brevity, we will address details of only one of these chunks -- the rules.
Section 2.4.1.?, which overviews the contol structure actually used,
will then sketch the other parts of the system's control,
emphasizing the advantages which come from "unitizing" these parts.
!2.4.1.2.1 Example - How RLL Encodes Rules
Each rule has a number of obvious attributes.
The primary facet of each rule is the actual code which is to be executed.
RLL spares the user the arduous task of enterring the
actual LISP expression to be run;
instead the user can type a more laconic high-level specification
of what this rule is to do.
RLL then "expands" this definition into that executable code.
(This is done in a very general, RLL-ish manner,
using facts stored in the name of the slot.
Hence it is the unit associated with the ThenTellUser slot which "knows" to
expand a message, like
("Do not breath this chemical, " Chemical "!!"
" It is " (Toxicity Chemical) ".")
into code which prints it when the user is present --
(PROGN (WriteToUser "Do not breath this chemical, " (GetVal Chemical) "!!")
(WriteToUser " It is " (GetVal (Toxicity Chemical)) "."))
)
*--------*--------*--------*--------*
Rule#332
Isa: (AnyRule)
Description: Tell the user to hold his breath if the chemical is toxic.
IfPotentallyRelevant: (APPLY ToxicP Chemical)
IfTrulyRelevant: (APPLY NearbyUser ChemicalHasSeepedTo)
ThenTellUser: ("Do not breath this chemical, " Chemical "!!"
" It is " (Toxicity Chemical) ".")
ThenAddToAgenda: EmergencyProcedures
Priority: High
OnTask: ImminentDanger
ImminentDanger
Description: This task tries to find if the current situation is
dangerous; and if so, suggest solutions/fixes/alternatives.
Isa: (AnyTask)
RuleList: (Rule#332, ...)
EmergencyProcedures
Description: This task is called iff the current situation is dangerous;
and issues many quick-and-dirty orders.
Isa: (AnyTask)
RuleList: (Rule#981, ...)
- Note the rule above is what the user would type.
RLL would use this to compute the actual to-be-run code, as it was needed.
*--------*--------*--------*--------*
There are several major advantages to
providing both high and low forms of a rule specification.
In addition to facilitating the creation of a new rules,
this higher level makes the nature of the rule easier to understand
and reason about, for both the user and RLL itself. [fnnote *]
[*footnote:
RLL is able to use different versions of the
definition of the procedure or slot for different type of tasks,
in much the same manner that InterLisp handles both compiled and interpreted
forms of each function.
When a user wishes to examine or edit a function, IL pulls in that function's
source listing, rather than force the user to peruse LAP code.
However it is that low-level LAP code which IL actually runs.
Similarly when someone wants to examine a rule,
(ie estimate how long it will take, or determine what sorts of things this
execution will affect,)
the rule's concise "declarative" form of the specification is offered.
This, of course, is NOT the form which is actually run.
The much-less-perspicious expanded form is used for this purpose.
This also represents a sizable savings of run-time speed.
Section 2.4.1.?.3 addresses this, and related, issues.]
The example above shows how the specifications for this rule is scattered about,
stored in several distinct slots.
This permits different parts to be executed independently --
for example, allowing the quick IfPotentially check to run to all of wide
class of rules; and then running the more expensive IfTrulyRelevant part
only on that small subset which passed.
The THEN parts are also split up.
In common practice, once the IF-parts have all passed, each
of the THEN parts is run, in the appropriate order.
The description above is
the way a rule is evaluated "by default" --
that is, unless the user has something else in mind.
Recall any user can readily modify that rule-evaluating procedure as well.
So, for example, the user may decide instead to execute the code stored
on the IfWorkingOnTask slot of a rule, or IfTodayIs, or any other set of slots.
rather than the current IfPotentiallyRelevant and IfTrulyRelevant slots
now used.
Or he may decide to compose a single Total-IF-Part, which ANDs together
all of these, and runs these at once. Similarly he may want the THEN parts
executed in a different order; or may have decided to only run those THEN parts
for which he has sufficient resources.
Note that this could not be done if each rule was simply a single piece
of compiled code.
We claimed above that it was easy to change the rule interpreter.
This is because that block of code is itself an RLL unit.
Like the rules, it is decomposed into nice sized chunks, which can
be independently modified.
One such hook is a list of slotnames which constitute
the IF part of a rule, together with a description of when that code should
be executed.
We will return to this point in the next section, which discusses the basic
control structure.
*--------*--------*--------*--------*
StandardRuleInterpreter
Isa: (AnyRuleInterpreter)
Description: This is the standard procedure used to interpret a given
rule. It first executes the AND-junction of the rule's
If-Parts. If the result is nonNIL, it executes all of
rule's Then-Parts.
HighLevelDefn: (IF (AND-Junction ProcessPart IfParts)
(AND-Junction ProcessPart ThenParts))
UsedByRules: (Rule#3 Rule#5 ...)
IfParts
Isa: (AnySlot)
Description: The value of this slot is the list of slots of the unit
(here a rule) which descend from the class, AnyIfPart.
These are ordered by the value of their respective
OrderForRuleParts.
HighLevelDefn: (PutInOrder (Subsetting MySlots
(ValueIncludes Isa AnyIfPart))
OrderForRuleParts)
MakesSenseFor: Rules
Datatype: Slots
Format: OrderedSetOfElements
Simplified version of the Standard Rule Interpreter.
Much of its code is "hidden" in the parts of the HighLevelDefn -- eg
IF, AND-Junction, ... Of course, these too are units, and are visible to the
interested user.
(The IfParts unit is shown, to dissuade those who do not believe this claim.)
*--------*--------*--------*--------*
Before leaving this rule description, there are several other
"declarative" facts which might be stored in each rule.
One important slot is the average CPU time this rule has spent, for executing
its IF parts and THEN parts, respectively. This can be used for various
meta-level reasoning tasks
-- such as deciding whether to even consider this rule
in the future (ie did its bang justify its bucks).
Another field is the rule's author - be in human or another rule.
This can help decide who to credit/blame for good/bad rules; and this data
can help the overall system to improve its performance by relying more and more
on capable (that is, successful) rule writers.
Finally, the user himself can store any other type of information he wants --
these are just things which we feel may be useful types of statistics.
Of course various inference schemes -- most importantly an inheritance hierarchy
-- are used to simplify data entry.
A new rule can be entered by merely copying that existing prototype,
and changing only those entries which are inappropriate.
Hence the bulk of the properties are simply inherited from more general ideas
-- here from RLL's facts about rules in general. *
[Fnnote*:
In fact, for pedagogic reasons, we might
tell the novice user only about a small subset of the slots he actually
might be able to change -- and let him believe that these are the only
things he can affect.
He would only be about this dimension of RLL's extendability
when
he begins to complain about how awkward it is to encode this or that fact,
or wonders why he can't seem to capture some particular type of idea.
Until that time, for example,
he would have nothing more that a "behaviour description"
of the rule interpreter
-- which is all he would ever know about the corresponding
evaluator in most other ESs.]
The above description of rules illustrates the degree of flexibility
available to the user at the designing stage.
The current RLL includes many rule interpreters which we, the RLL designers,
felt were appropriate and useful.
It is important to realize, however, that the eventual user is not limited
to only these.
Not only is he free to design his own interpreters,
but RLL aids in this mission, by providing tools which facilitate
constructing such interpreters.
Indeed, as these tools are represented in RLL as well, the user can even
construct his own building aids, if he feels the need.
There are similar mechanisms for implementing the processes used for
"running" agendae, or tasks, or other control regimes.
(For example a black board architecture, for other types of tasks.)
Corresponding to each such process is the data structure to which
it applies; and RLL includes means for extending or adapting those as well
-- ways of extending tasks, for instance.
This section tried to demonstrate how useful RLL's competence
in this programming domain
is when designing and building a new expert system.
The next subsection shows another application of this facility --
when the user wishes to modify his existing ES.
Here the user has the option of changing his mind later,
and know that RLL will modify not only the code,
but perform the retroactive updates to his data required to keep code and data
in synch.
!2.4.1.2.2 RLL's Modifiability
Different system have different conventions defining what part of the running
system is changable, and which is, to all but the most sophisticated user,
untouchable. By design even casual users can enter, change or delete
"domain data" -- facts, in this case, about the connectivity of pipes,
or the precise placements of various buildings.
(Eg if the user later realizes that
Pipe#406 really joined Pipe#317, rather than Pipe#316 as you had thought.)
In many representations systems,
the user can addres and modify generic objects as well --
for example, respecify which features are well-defined for types of roads,
or redraw the taxonomical information about types of oil.
In addition to these, some languages
permit the user to define totally new types of
relations -- in the form of new slots for our RLL language.
(For example, the FeedsInto slot which was handily defined as the
Composition of the OtherEnd and the ConnectedPipes slots.)
These definitions can be used to redefine the "meaning" of a slot as
well as initiate one.
Suppose you realized that pipes could really join many pipes, rather
than just one. This would be difficult to say in many languages --
indeed the only solution in most might require throwing away that FeedsInto
link and defining a totally new FeedsIntoS link.
Even then all of the existing
data would have to be transfered, regrettably by hand.
In RLL, on the other hand, all of the executable code is made explicit,
and the user is permitted to modify it to suit his design.
As section ? pointed out, RLL provides various tools for such adaptations --
for example, the high level specification language for functions,
and the use of appropriately chunking the knowledge.
(These are the same things which proved so useful for constructing of parts
-- but it is also be exploited for retro-actively modifying existing parts.)
RLL's uniform representation of facts makes
changing the code as easy as altering any domain data
-- as the facts which specifies a slot's arity is in the same format
as data about Oil#31, or any other domain or representation fact.
Furthermore, RLL's "understanding" of things like SingleElement and SetOfElements
allows it to do all the appropriate fixes, automatically.
RLL extends this modifiability to include the control structure as well.
This permits the user to
construct his own form of control, as he needs it.
The next section outlines the contol structure we found useful for this
particular Oil Spill task. We wish to emphasize, again, that this Agenda
mechanism is but one of several control structures which will appear in the
mature RLL product -- and that the user could have designed his own from
smaller pieces supplied by RLL, using tools present in RLL.
!2.4.1.3 Control
The decision of which
type of the control structure, and the appropriate set of inference algorithms,
should be based on the desired characteristics of the eventual system.
For example,
the complete OSS is expected to perform a variety of different tasks
-- from determining the type of the spill to performing various
remediation tasks, such as notifying the authorities.
Another important characteristic of this job is the timeliness and ordering
of these tasks --
the importance of recording the name of first witness dwindles when
compared with telling him not to breathe the toxic fumes.
Hence determining the toxicity of the vapors should be of tantamont importance,
especially when the leak might be near people.
A well structured agenda seemed ideally suited to these specifications.
(An additional plus was that
even this still immature RLL system already had this program construct.)
This Control subsection has three other parts. The first is simply
a quick behaviour sketch of this overall mechanism. The second part goes
into more detail, describing how these chunks of code were generated,
encoded, and processed.
These descriptions seem to imply the RLL must, necessarily, be hideously slow.
This is NOT the case.
The third part specifically addresses the issues of speed and efficiency --
a sufficiently important, and misunderstood,
point that it deserved to be included in this description of RLL.
!2.4.1.3.1 Overview of Agenda Mechanism
The agenda contains an ordered list of tasks, which are processed sequentially.
Each task is designed to performs a particular bitesize job.
For example, the goal of one task may be to determine the values
of some parameters, (e.g. the task MatType attempted to deduce
the type of material which had spilt,)
another may add other tasks to this agenda,
(for example, the task in charge of effecting the Countermeasures added
several new tasks to the agenda - one to notify the authorities, another to
begin the clean up process, etc.)
and a third type would print out instructions/requests to the user
(eg "go to Manhole #34 and tell me if you see oil").
There were several other (pre-existings) kinds of tasks
which were not necessary for this particular domain --
for example, one type could suggest and create a new concept,
while another might decide to rearrange the tasks on the current agenda
in recognition of some new fact.
In general, executing a task involves
first collecting relevant rules, then ordering and firing
this list in sequence.
(For this limited oil spill project, this collection step was trivial --
it was simply looking up the set of rules pre-stored on each particular task.)
There are many types of rules, each charged with (attempting to) achieve a
different type of goal.
(In this sense they are similar to tasks, only in a smaller scale.)
Some rules employ a known technique (algorithm) to evaluate
the value of some attribute.
(For example, determining the toxicity of a given material by looking
it up in a table.)
Others may decide to add additional rules to this rule-set,
or propose adding a particular new task to the agenda.
Still others may suggest that the current task (in which this rules occurs)
be suspended, to await necessary new data.
(Note the flow of command is quite structured.
Each rule, task or agenda* can only effect its immediate surroundings.
More global changes are performing to sending messages to its overlord,
proposing this alteration.)
* Footnote: RLL (EURISKO) is capable of dealing with several agendae --
swapping among them as need arises.
This facility was one of many RLL features which were not needed
for this job.
!2.4.1.3.2 The Details of the Agenda Mechanism
We chose to view each part of the overall control as a process --
each operation took some prescribed type of input, and performed
some action, possibly returning a result.
As sketch in the previous subsection, the "Agenda-Processor" looked like this:
Initialize <Agenda>
Loop thru <Tasks>:
Get next <Task>, T
Process T
PostMortem <Agenda>.
The "Task-Processor" is (not surprisingly) similar:
Initialize <Task>
Loop thru <Rules>:
Get next <Rule>, R
Process R
PostMortem <Rule>.
as is the overall OSS Process -
Initialize <OSS-System>
Loop thru <Agenda>:
Get next <Agenda>, A
Process A
PostMortem <OSS-System>.
This commonality was factored out, and exploited by defining the
EuriskoProcess * unit, shown below,
as a common "ancestor" to both task-processors and agenda-processors
(as well as other types and levels of control structure - such as the overall
top-level systems for both Eurisko and this OSS projects).
[*fnnote: RLL was developed as the underpinnings for the EURISKO project,
described in [?]. As this system relies on a sophisticated, and modifiable
agenda mechanism, this control structure was the first one developed and
incorporated into RLL.]
-----
AnyEuriskoProcess
Isa: (AnyClassOfObjects)
SuperClass: (AnyProcess)
SubClass: (AnyTaskProcess, AnyAgendaProcess, ...)
Examples: (FullEURISKO-System, FullOSS-System ...)
TypicalExample: TypicalEuriskoProcess
...
TypicalEuriskoProcess
TypicalExampleOf: AnyEuriskoProcess
FunctionalSlots: (LispFn ToInitialize ToSelectNextSub ToXeqSub
ToPostMortem)
...
-----
Now defining the task processor is fairly straightforward --
first create the OSS-TaskProcessor unit as an example of
AnyTaskProcess, and then fill in the values of its functional slots:
ToInitialize, ToSelectNextSub, ToXeqSub, and ToPostMortem.
(As we'll see in a moment, the value of LispFn is generated from these
components. As such the user is NOT expected to enter this value.)
Actually the user's chore is further simplified as any of these slots
he leaves unspecified defaults to the value of the corresponding slot of
TypicalTaskProcess. *
[*fnnote:
This only works because the various involved slots are all "inheritable
slots" -- ie their respective values can be determined by following
the inheritance paths; and because
the first prototype these tasks will find is TypicalTaskProcess.]
-----
AnyTaskProcess
Isa: (AnyClassOfObjects)
SuperClass: (AnyEuriskoProcess)
SubClass: ()
Examples: (OSS-Task-Process)
TypicalExample: TypicalTaskProcess
...
TypicalTaskProcess
TypicalExampleOf: AnyTaskProcess
ToInitialize: DefaultTaskInitializer
ToSelectNextSub: DefaultRuleSelector
ToXeqSub: DefaultRuleProcessor
ToPostMortem: DefaultTaskPostMortemor
...
-----
These "functions",
DefaultTaskInitializer, DefaultRuleSelector, etc., are themselves units,
which the user can examine and modify, if desired.
The "LispFn" of this OSS-TaskProcessor is now filled in, by connecting the
code present (or virtually present) in the various functional slots of the
OSS-TaskProcessor unit, to correspond to the schema shown in above.
Unfortunately, at this point, no one (or rather, no task)
knows about this nice assembled clump of code.
To tie it in, each task which wants to use it must point to this
OSS-TaskProcessor. Setting the value of Task#34:ToProcessMe to
OSS-TaskProcessor achieves ths effect.
In fact, as the value of this ToProcessMe slot is inheritable, setting
the value of
TypicalOSSTask:ToProcessMe to this OSS-TaskProcessor means everything
which includes TypicalOSSTask as a prototype will use
OSS-TaskProcessor by default
-- unless the user, wanting
a different task processor to be used for this particular task,
explicitly stored the name of that processor on this slot.
Creating the OSS-AgendaProcessor is quite similar,
here exploiting facts stored on TypicalAgendaProcessor as needed.
You may note that it is the Agenda controller which decides what to do
with each task. By default, each agenda "processes" each of its tasks,
using the mechanism which looks on that task's ToProcessMe slot, and
calls that function on this task. Of course, the agenda is not forced
to do this -- it may "know better", and use some other task-processor --
for example, on which is less accurate but quicker, for all the tasks.
Or it may only use this power sometimes, for example, if the agenda processor
is told that storage space is low, or whatever.
!2.4.1.3.3 Efficiency
From the above descriptions, one may infer that RLL is actually
"executing" high level
specifications of various control algorithms that the user input.
Were this true, RLL would have sacrificed any hope for speed and
(time-)efficiency for the sake of flexibility.
That is NOT the case.
As we showed earlier
(footnote on p. ?), RLL preserves both these high level descriptions
definitions, AND what these forms "compile" into -- and it
is that latter body of fast code which is actually run.
Much of RLL boot-strapping code is devoted to maintaining
these correspondences --
so that any change to a high level form marks the (formerly-)corresponding
executable code as invalid. On demand (thatis, the nexpλAi%[BAi!ChAG=IJ~∃%bA]K∃IKHX$A%→_↓oSYX↓KqaC9HAiQ¬hA]K\AQSO AYKm∃XAIK→S]Si%←\AS9i↑AeU]]CE1J~∃G=IJvA¬]HAgQ←eJAQQKgJ↓YWnA1KmKX↓MWe[LAg↑AQQKrA]SYXA¬GGKgMKHAgAKKIS1r~∃]∃q`⊃β&K7*∞Mε*ε=|F*ε≡4εv.\LV"pQ!PU⊗↑NW⊗v≥lrεv}tπ&z∞Mε*π≡XW∨&≥⎇bε}d V66≤=⊗.v?∃Bπ>T∞6.*∞Mε∂"
)Db?4 6}&QQ&≡∞d &*ε≤,&O',≡&Ng∀λf∂∨Edαh*,↔&F↑$π&F≥dαεNnLW↔π,↑B$≥~→$
~9z∧
→=Y-D→→<l>Z<≥
≥{\k∧
S∪λ m<\u∧∧X{{.
;→<d!"]~ ↑y(~-n≠h→,lZ8z,]]λ⊂∪≠y6yVλ0w2≤:w9P≥44yP→0yz2\⊂1wb→WεE*~4yP1[yz9P≠w6<P_P1ww≤z0w:λ7{2y~2pr⊂ VP3'\⊂:42H7w2P≥4vrP_t0y3YP7s⊂βE2|8_w24w→P:40]⊂:2y≤rP22\qy4x≥4ww↔λ⊂#97[P:42\2P7wλ:42P_wr2P_pw⊂1→FE0y_4z90\4v<P→s34qZrw:↔βE!0yZqpv6≡P)&&λ40yP≤0tr⊂→7y⊂4]9P36→|4q4[4z<P~w⊂:2\6yP7Y⊂9x0XrP⊗VH:7P6Xtw:0ZwεE:~2P24Y32y2[:⊂;2\9tww≤P7s⊂≥42P1[r2P⊗KP0w2λ77z⊂~w⊂:4[rWεE∪wy2P→2z0t[9P7wλ47{P≥42yrH6zv:~x62P≥2y9t[w9P0\2P6pZw:0t[2r⊗⊂≥yrr⊂_w2⊂1Xqt2rβE1pwλ12P3≠zw2~w⊂-f→w0z⊂→z⊂0v↔P0w2λ-cy2Zw2y.KεEεEλY↔~↔ W~⊂⊂∀|yz2[P#0qZv4z4YyFEεB∧kdg∀FE*4→P92x≠y:⊗⊂≤wP30\⊗⊂40\P2vx~0yt⎇→r⊂)&∪∪yP9]92w3]49PεB;t4qZ⊂22y~{2P3≤7vP4]∪yP⊃_wvx2]2w1rH6wr2[⊃⊂7sλ897s\0vvt[3P4wλ3rw2\0v⊗εB0w2⊂≠s⊂:4→P20z_P9z9≥qz:y→yP0w→⊂0v3[y4z4≠yP4zλ:yryH4w⊂8_y:4q]v0y↔βE&pw≡P7s⊂~z9P7]42y⊂≥tw9P_y2P2≥rP:7H4z9P→w;4y≠w6rw≥↔εE!→qpziYP4z⊂~yP4yH1:tv≥⊂7w⊂≥7x⊂7Y⊂!gi∪&⊗εE_P22vXw2⊂8_stw3H9|yz→vP-aSi&&.KεE)&∪⊂4yP_q62P≥7FE4Yw7y2H$w:2\&4yx yP→~M%P9z≠y0srH6p|4[zvVεB0w2⊂≤z7y2H0w⊂0[6wyzλ:w64[tz2rλ7:vq→y⊂7sλ:w4z≤WεE']42y⊂_4sP0Y;0w:_sryP_wvrP→97vP∩w:2y∪4yx⊂~z9rv→⊂⊗VFB4w1v≥r4w3H:44w→yP64ZrP9x→v64w→P1wy≤2qz4[w⊂0w→⊂4w6~w2P2Y4z7y≤WεEεBεE∧f∪iibiCE)&& yP14Ysryzλ897q≠2vV⊂_z⊂:4~yP9z_srP7Y⊂4z9H22{2[7x6r[:⊗⊂4\P4z9H4vvp]:y4z≡WεE!≡P22yZsw⊗⊂~z⊂;t[6⊂1w[:4w:[zyv<H4w1w\87y0]2P72]P30q]9P0q≠zz⊂1[w:97[⊂9z9≥qz:y→yVεE→7y6yH7s⊂9→x92yYw:0z~ww⊂0[2⊂6wY2yP7Y⊂4w4→y4z0[1rWεB$7{r]2y⊗⊂∪iiP;XyP1:Zv:⊂;X|P:7[P2py≠<P4wλ:44yH7w3wZw3P2→ytswλ897qYyyWεB#7y⊂→|0vx≠2V⊂)∪&⊂40Y⊂72{→y⊂2w_wzw:→y2r⊂_P)wv≥0q62H(97q≠2vP1→s7y2H⊗VFE_v6⊂7Y⊂4z9H892{~wzyP≥wy5P~0r⊂1→rw⊂2~y2qz→r⊂:7]py29H fVv~urP9Ypy1t→yP⊗VCE:44[3yP;Z4qt⊂≠2{2yλ:2y6Zw0v⊂≥tz4⊂_P34w_v⊂;2\24qzλ∀4rP∀&&⊂5[2{P0X7zz⊂≥0yuyCE64uYP⊃#4[2⊂2|_vx62\P7s⊂≤94vr\Q⊗⊂1≥z⊂77]⊂0q7]z⊂:4~w3yP≠4urPλ+t0zλ4yP:~2P9w]y1rFB7s⊂:~2P9x~v6⊃∀KεEεE⊂w7z4→y⊂14YP;rpZw2yyK⊂;t4Xt⊂0v≤wP9z→vvrrλ397vH4z9P≡wzz4 ⊂;pyH4z9P≠0quP≠sεE0H:yryλ397w≥⊂2w2 ⊂⊂ P≥94{4Xv⊂2|_vx62H4w;7[;2yP≥42P;X|P;rH;ry2H37y1Yr⊂:7CE2w:→y⊂:4→P1wr→P⊗VP→{2y<]44w3H;pyP~w⊂0P∪$ih<H∀#rz∃0v:rH∪fpz→y4pvβE∪g0[rTV⊂≤0z42\⊂:40[⊂0P7~qry⊂λ&pz2\4pv∪\P70vYQ↔εE⊂z⊂0P→2rx2\⊂62{→v⊗⊂)∪&⊂24Y⊂77zλ<rz⊂~0{2P_w<P7≠z4wwλ7s⊂1[w:2|≥⊂⊗VFB:44yH37y1Yr⊂:yH22ytYw2y9H:7P2↑864qZz6<P≥<x2P
1ww:~w:tw→P:42H0q7{→P2|0[x62TCE⊃&p]2y4p[⊂70vYQ⊂90]42y⊂≥40w⊂≥42P∀≤zs34Xtrw:
P⊃70[rQ↔εBεE P→wwr⊂→97w:λ2w2⊂_wzv2λ40{2H0tr2Y⊂4w⊂≥42P2→ytswλ7s⊂:~4yP9↑yz2vK⊂1<P≤zssr\z4w3CE0x8≤7x94Xz2P2_z0P9]9:qz≥y2yP_w2⊂0[3wy4]46yP_yP;rH;rw: ⊂⊂*4~yP:7[P;pyH6tyyZw3WεBεE w≠z42yλ9|yz→vP92[0z2rλ9t7y≥⊗qwvZw3V⊂_sptwλ2x42[ry0v ⊂4yP∀&&∪yH22x2[22w1↑P7wεB$w:2\&4yx ⊂⊂'z\⊂67w→P:2y≠P860[9P0y→P:7P_:tv2λ)&&⊂~w:7P_P6wr≥v2P;Z4qt⊂_pwεE_2P9:[⊂4w⊂∪i)P-Si)nP
;rSv≠⊂92z≥y7⊂:≠P:44\P87t[:⊂4wλ:42P⊂ww1v≥ytww
WεE)∪&⊂;t[6⊗⊂0]⊂:40]⊂87t[:⊗⊂4[42y4]εE:4→P6pqZ4w2P_w2⊂&∩ih⊗r~pv2q]⊂4w2→x2w2→w1rP≠s⊂&i∀WεEεB)&&∪\P34w_v⊂6pZ7y⊂3_zv:⊂≤rrvyH0v6w\z⊂80\0r7|~qpv≥βE4z⊂≥pyP4]∪yP4[vrw9YP0r0\:0q4[4z<WβE*7wH6zqtλ392rY7vV⊂≥rP37]w2⊗⊂→7y1rY⊂:yP≥7P9x→w2⊂1[w9tr→y0q6→P:4vYFE22Xtr4w→P;t4Xt⊂92Xv6<P≥pyP:~2P12\z↔εE∃44yP≥4vrVλ7s⊂1[zy9rK⊂;pyH77z⊂~v6⊗y\2w:≥H:42P→4w0vλ'iiP~yP1r\:0tw≠<FE1→z:2yλ:40wλ:42P≤97r:Xz⊂7sλ0w<P≤|yz2[P;t4Xt⊂37\1rr⊂≠zz⊂4_w2⊂0]⊂2pqZ⊂9z2\⊗εE6[v24w→P7zyλ34w0[⊂1wr→P:7P≠pz1tλ:42P⊃ia8∪\P64vZz2r⊂≤rz⊂7Y⊂:ypX62P1[vx7w→w:9WβE$7{Y{2y⊗λ0yP9]qt⊂2↑:2y7_v⊂1w[9z0t[:9P;[zv2⊂_ry:0Zw6<P~0{2FB70y9≠{rr⊂→7{w⊂≠zy⊂)Ypy1t ⊂;rP≠tst:λ2{2wλ40{"H34w4\t⊂:4→P9|y]2vP4[⊂:42CE37z\⊂20|\P;rP≥ry2P_v67z≥2r↔εB'w1rH0spt[⊂:44\P:<x→P7s⊂≤97q6→vP1g]v2⊂4_{2P1→rw⊂0[62{4Xz2r⊂~w⊂0@≠wy2FB6pz:\2P9|\z2vVλ;t4qZ⊂4w1[8r2rλ0P1w[x2z2[:⊂39≠w:⊂"[2⊂;t~qt⊂;[zv2⊂~0{2FB9ry;→r⊂0yH⊃3rw≥62P3]tr2Qλ2:y4[3P:4~yP1:Zv24w→P897XryyWβEαE⊂L↔~↔_K~P⊂![w1v:\tp∂n
We will conclqde win a perspective of RLL -- iN terms of its past, its
current status, andour Long term plafs.
¬
Two years ago,
RLL Began as a two week project to build a represEntation lAnguage on
which the EURISKO System would be built,
We soon realized many non-triviAl research issues had to be addressed before
such a general, "self-encoding" lAnguage could be constructed.
(We eventually abandoned the quast for this ultimate lAnguage, satisf@eS]N~)←keg∃YeKf↓oSiP↓iQJA≥K]Ke¬YSir↓oQSG AoCf↓a←gg%EYJA]SiQS8ABAY%[SiK⊂AgKh↓←L~∃
←]giICS]iL\@A)!JA[←IJAiQ∃←eSi%GCXA¬gaKGQfA←L↓iQSf↓eKae∃gC]i¬iS←\↓YC]OUCOJ~)YCMOUCOJA]←eVA]CfAi¬WK\AU`~∃EdA←iQ∃dA[K5EKef↓←DAi!JA⊃¬↓β∂?nkW;''Imβπv!βS#.KAβ;/CQβO&+Aβ'~β∪↔O≥∪' ↔"β'8∀UZ6JNjq$4(hRS#∃ε≠WKK.sQβOO≠S↔5πβ3πg~β¬β;.≠↔OO∂∪eβ }{Q7O'∪πCCNs≥βK}c∃↓5jβ∂↔K& '9βε KSLhS? β&C∃βOO≠S↔5εkWOQε∪∃βC⊗+Oπ;"aβπMπ##↔O*βπK∃π+O↔⊃π#=β≠Lc1β'rβ?S#/⊃βCπ↔#M84RB≠?Iε+cπ7εc∃1β&C∃β∂}#∃β←FK∂!βO→βWO.!βS=ε+cCπv!β#'>Aβ3↔6+1β∪.3';'&K?;MεkWOPhS ∃βπ∪↔O↔w!↓55ε{@∩ε≡@εf.≡>Bε.mzV>B
|bεOD
Fzε|]f/⊗≡LRπ& Tπ⊗/>Dε}2∞Mε*Q)↔'≡]LbrHQ!PTNβH∃
(≠⊂↔[will actually build RLL into the MRS system -- viewing
each of the seperate decomposable parts of this systems as an MRS module,
which can be individually or collectively plugged in (ie activated).
Using MRS as a Lingua Franca, RLL will be able to absorb a large corpus
of knowledge and examples from a multitude of users -- the MRS community.
Each of these other modules will hold facts about a particular domain, or
part of that domain -- eg Medical tutoring, VLSI design, or planning experiments
in the field of Genetics.
For its part,
these RLL-based MRS modules will store facts about certain types of representations,
together with their major applications.
Important in this list will be expertise about expertise.
It is this knowledge which will enable RLL to fashion new ESs with greater
efficient and accuracy.
BOTTOM LINE
While other ESBp systems have proven expedient for tackling particular problems
in particular domains, such systems seem inescapably limited
in the scope of problems they can solve.
We feel this problem is intrinsic to such ESBps, at least until
they, like the human programmers they are trying to emulate,
are capable of a crude understanding of the code they are attempting to
to compose -- an understanding which is far deeper
than the superficial level any current system (including RLL) has yet achieved.
RLL was written with the goal of attaining this necessary
undertanding.
! BIBLIOGRAPHY
[Greiner80] - "RLL-1: ..."
[Greiner & Lenat80a] - AAAI
[Greiner & Lenat80b] - Details of RLL
[Lenat, Hayes-Roth, & Waterman] - Cognitive Economy
[Smith] CORLL
[Genesereth, Greiner & Smith] - MRS
CHI, FOL, LISP...
[DBL's version, from last page]
(17 July 1981)
Draft of RLL section of Building Expert Systems
2.4.1 RLL
Expert systems evolved to help (human) domain experts manage both the bulk
and the complexities associated with knowledge-intensive tasks. One
interesting and important observation is that the task of building expert
systems is itself a suitable one to make the target of an expert system.
This realization triggered the development of RLL, a representation
language language.
RLL is, first, a collection of tools which help the knowledge engineer
(KE) construct, use, and adapt expert system programs. In addition, it is
itself a bona-fide expert system -- knowledgable in facts about
programming in general, and its own subroutines in particular. This
competency permits RLL to "understand" its internal inference procedures,
and provides the user with a mechanism -- simple editing of the
descriptions of those subroutines -- for modifying the RLL environment to
suit his current task. All too often, KEs have had to twist the facts,
rules, relations, etc. of a task in order to fit it into some rigid
representation scheme.
This section will quickly overview this RLL system, taking examples from
our experience coding up OSS -- the Oil Spill System. We hope to show the
gains from self-describing and self-modifying software, as well as
presenting techniques for recapturing any of the efficiency lost by going
down this route.
!2.4.1.1 Overview of RLL
The hallmark of an expert system is competence in some task domain.
Usually, this does not extend to comptence in meta-cognition, an ability
for a program to reason about its own structure and behavior. MYCIN,
e.g., doesn't "know" that it uses a backward chaining inference engine to
perform its deductions, let alone WHY it uses such a control structure.
AGE, e.g., cannot answer questions about the efficiencies of itself or of
the programs it write, nor can it modify its basic Blackboard model to
handle, say, a different type of rule.
RLL begins, as does each KE himslef, with a library of useful, common
types of slots (IsA, Inverse, RangeType, and several hundred others)
control mechanisms, (backward chaining, agendae, and a few others) and
inheritance schemes. Each of these is represented internally in RLL as a
unit, a frame-like data structure of attributes (slots) and values. Thus,
each kind of slot, each kind of control scheme, each inheritance mode is
described within RLL's formalisms. Some od the units are standard
mechanisms for modifying "domain knowledge", and they can now serve to
modify any part of RLL itself. One dangerous consequence of this
philosophy is that they can modify themselves, perhaps destroying the
ability of the system thenceforth to be self-modifying.
At any moment, some ensemble of the units are combined into a description
of the desired current system, and RLL behaves in the prescribed manner.
That ensemble defines a representation language which the KE can "freeze"
if he desires, and use for some particular application he must build.
This is the reason we call RLL a representation language language. No
single set of starting primitives could possibly satisfy all of the users
all of the time.
To help the KE tailor the language to his current task, RLL provides a
number of tools (all represented as RLL units, of course) which the user
can use in constructing his own pieces, and in combining pieces into
ensembles. For example, the user can easily create a new type of slot or
inheritance procedure. Typically, he would copy a similar existing unit
and edit that copy. RLL then "compiles" the changed description into
executable code.
RLL's competence model of programming comes in at this point. There are
many indirect ramifications which arise when, say, a new laboratory
technique is added to Molgen's data base; similarly there are a host of
actions which must be taken when some part of the underlying
representation is changed. Just as Molgen's code is responsible for
propogating the effects of this new data, so the overall RLL system will
find the parts of the system which may be affected by this change, and
update these pieces appropriately.
RLL allows the specifics of a problem to guide the nature and
implementation of the user's final ES -- rather than force the system into
some particular formalism.
The reaminder of this section fleshes out our so-far skeletal description
of RLL. Subsection 2.4.1.2 explains how facts are represented in RLL ,
and shows how this structure is adequate to handle knowledge about both
the particular domain (eg Oil Spills) and RLL internals themselves (eg
facts about slots or control mechanisms). This section includes a
concrete example, using RLL's management of rules to show first how the
facts are stored, and then how various type of modifications can be done
-- ie how RLL has attained this degree of flexibility. Section 2.4.1.3
describes the control structure used for this partcular OSS application,
in a fair amount of detail. This section also explains how RLL can
provide the self-describing and self-modifying abilities discussed
previously, and yet retain (recapture) almost all the efficiency of a
hand-tailored system. The final two sections describe how RLL fits into
the world, and what yet remains to be done.
!2.4.1.2 Knowledge Representation in RLL
RLL is based on the "To every thing, a unit" philosophy. This uniform
representation system extends to all domain knowledge (e.g., units for
each type of oil and each pipe junction), and also to all repreentation
knowledge (e.g., units for the Viscosity type of slot and for the
BackChain control regime).
*--------*--------*--------*--------*
M6-2
Isa: (AnyManhole)
FeedsFrom: (M6-3 M6-2)
FeedsInto: M6-9
AnyManhole
Isa: (AnyClassOfPhysObjects)
Examples: (M6-2, M6-3, ...)
Description: The class of all manholes.
Isa
Isa: (AnySlot)
Inverse: (Examples)
Description: The slot signifying membership in a class.
MakesSenseFor: (Anything)
FeedsFrom
Isa: (AnySlot OilSpillConcept)
Inverse: FeedsInto
Description: The slot naming the upstream manholes.
MakesSenseFor: (AnyManhole)
*--------*--------*--------*--------*
RLL is, for better or worse, committed to using a particular
representation at its heart, though the apparent one seen by the user may
easily be changed, and in principle the innermost RLL might be as well.
That representation comprises a semantic network, with each node being a
structured frame-like "unit" whose attributes (slots) are defined with a
set of property-value pairs. We will show below the great fhexibility RLL
doeq provide, within this constpaant. We use the notation Mil:Isa to
refer @Q↑AiQ∀AmCYUJA←L↓iQJA%gBAg1←hA←_AiQJ↓k]Sh↓∨SH\4∀~∃)!JAMSIghAk9ShAS8AiQJ↓E←pA¬E←mJ↓eKMKIfAi↑↓BAga∃GSMS A←EU∃GifA]QSGPAKqSMif~∃%\AiQ∀AeKC0Ao←e1H@ZZ↓~lZd↓eKae∃gC]iLA[C]!←YJ@ dA←\↓oCiKIYS]JFl\@↓)QJA9Kqh~)k]Sh↓eKae∃gC]iL@ABAα≠3πO~↓β?→πβ#gON≠π1↓ε{ +↔∨#Mmα∞sf7πvC?3∃αβ↔;∂}#↔M↓ε3π∂S_h+π ␈+QβSF)βO↔"↓β?→ε 31↓εkπ;#|c↔M9ααS#∃εs↔cQαβS←=π+;'S~↓βK↔π∪↔O↔w!β/'v#M↓β}04+Of{SM9αα?→β≡{WKO*βS#↔⊗)βπK*β∪?k.sMβ?2↓βO3␈#Eβπ↔≠↔;Q∧3K?5π##∃β.s'SM∧K9↓β&C∀4+6K∨WK*↓↓#∃v991↓¬;?KSB↓β?→αα5Y5∩a↓α∂∂∪∪';∞c'Seαβ?→↓∧ ;f7∞s#?3*a↓α≠␈∪7πQαβ?_4T3↔↔∪≤3K?5Jp4(Q*6}nT∞GOε↑4ε}2∧∞VvON4αF*lubbα∞Mε␈≡T∞&/π,↑6.wM≥f:ε↑lVw'5∀αε≡≥dεF∂lTαπ6≡/⊗NvqQ&&.},V/~
|bε>]lW⊗∞M≡GJr∧λ6}w=≤F/∩ ≥bε/ ≥WεfW$αα¬|Tεn∂∀∞v∞wD∞Fzπ<∨∩αε|]f/⊗≥APW&
≥f?~ ≤&␈/D vNb∞>εNfM≥f:α
≥g&z ∀ε⊗}O∀αε}d∞v∂&↑$αjj \rbα∞Mε∂"
≡Bε≡≡Z6/~∧ ⊂hW= V.rd∧∧Nε\≥FgJ ≥Fbα∞>V≡B l⊗∨'4∧π≡F}]F"ε,Tπ∨&},V"α
≥bε}lTαπεL≤6*b∞<↔Jα∞Mε(h)x
-J|~;
M;Yr-n≠ux.L<H≥-m= λ
≥Hλ≤n\zλ_$
8;[L↑Hλ∃
=λ→.l<↑(
]|Y(∧∞|→8m≤;~>L\β"Pl≡y+λ∞⎇;≠λ ≡=≠{,≡~8x-M≤∧P⊂~w42`2it these facts. We want RLL to conclu` J~)iQChαβ?'1¬≠C'3dK;≥βNsS=βλβOSK. 5β←Nc1β∂∂+O∃βλ∧π∞F\X D
;H≥
=λ≤nNY8;$
{Xy$∧~=β!-{[unP⊂⊂⊂≥40z OilSpillingIntoStpeam is a specialization oF
OilSpilLingIntkWater. We could go on to describe facts about
αOIlBromPipe93SpillingIntoWOC( a unit which, in turn, can be fqrther
Restrictedinto MachineOilFromPipe93SpillingIntoWO@πβMi∃e∨ki→CYXrLX@Ao!SGP~)GC\@@@@@@@@@@@@@@AEJ@@@@@@@@@@@@@@Ae∃gieS
iKH@@@@@@@@@@@@@@Ai↑4∃↓Cs=YI≠C
QS]K=SXFe→e←[!%aJrf≥g
SeMi∨ki1Ki'a%YYS]≥∪]i←]∨εZ~)βMiKI∨ki
¬YXrg=]βkNβ⊃M9↓∧≠3↔π⊗ceβ←*↓β∪=∧r>Qβ> ;Q↓π#=βOε ←9βλ↓β;↔:βW;' ↓β≠?⊂h+↔[-∪eβC}K;Q↓εK9↓βrk∪'7,¬g≡N⎇l⊗bα∞>ε∞≡Udαα∧∀∧εv/t∧π.v≡@αεO4∧εv/lX D∧≤≤[lN8y9↓QX<XM≡≤X<M≥≡+λ .=λ≤L≡~→<D
{[≡$∞z→;D∞~→4LT~<h∞={9(∞ <]~-l;]λ l8⎇λ∞Mh≤≤L↑y<]LQ"X8M}=λ∃
(→5L]] @∧
z→;D∧≥~→$ X8⎇∧
<hλ |;Y<L≥ λ∩.D→{y.∀λ≠{D (→y-l<X;∧∧→=Y-nβ"]-m= λ∞⎇~8z∧ ;X8ML<h~.Nh→→.<y;Y ≥]≤h∞Mh~;M <Z=∧∞~→<lT→X8nNkC"AQU~→$
98z ≥Z<{$ [|H
;Y≠
≥Yh≥
<h≥∂≡→(λ
|H~;M <Z= ≥Xy(
≡h→~.>~;XnD→\[mTλ≥~ Q"[;n,(≤⎇ ≥Y_<LD⊃;→-\;]∪lD≠|H∧
⎇8\l↑∪yH∞,;_=
≥{\k∧ ;Y∧∞z≠⎇-Lλ_Y$∞≤Y8.L9λλ ≡c"\n\z H∧
S∪λ
≥\⎇<L↑h≥~
≡h≤y. <X=
≥{H_O∀_;≠
|x=~-lh→~,lY<Y-nλ≥;M≡≤h≥
tλ≤⎇
}Y#"Ll8⎇≤d 8[⎇.Dλ→8,=λλ≥∂≡→(λ
|Hλ∩-m→<Z.L;Xy%dλλ∃L≡X;⎇.4λ≤≤M}→<]
≤<hλ
|Hλ≥
<y#!-;Z→.-=_;L<+9→,m;Z3Lt≥;Z.Nhλ~-l~8x.L(λ~
}h≥≠d∧~;Z.M8;~/,(λ_$
Y=h∧∞;Z5∧∧
_<aQ\⎇_.M;Yh∞M_=
<→(f6hλ~.∀_;H∧λ>_;.
→(≠l@⊂⊂ w≡h4x2H9t7z[2⊂⊂1→P40w→62rλ8ztz→FE24Y32y2[:6<Pλ397vH⊂⊂:4→P⊂⊂9]0z2vYw:⊂⊂≥40zλ⊂'tv∀x4v6~w3dw≥7iz9→pvP⊂λ4yP⊂λ0FE)\2qtp[4⎇0z~ww⊂7Y⊂'tv∀x4v6~w3dw≥7kpz→y∀V⊂λ7y⊂4≠{P:4→P⊂;0[:ryP≠s⊂9w[rP⊂9[7zεE≠p|P1→P0v:→y2r⊗λ:7P6Xts:0Zw⊂:4~yP80\:4qz[0y⊂$[42y4]0w1bH92v0]4ww↔λ⊂∀2`' the
SubstafcESpilt of any SPecialization, S, of OilSpillingIntoWater must be
some refinement of Oil, whereas S:TimeOfSpill can be arbitrary.
Analogously Pipe#33 can have slots like Length or TimeOfCreation, but not
things like Father or RangeType.)
Exactly how such data is encOded is far too detailed (and irrelevant) for
this report; the important fact is that such facts can be stated precisely
and explicitly in RLL. Furthermore, such facts can be altered by the
User, if his task demands it. Indeed, the user can eveN create new
"representational pieces": As none of RLL's priop tasks had needed this
Specialization inheri`)¬]GJXA←kdAgiCIiS]NAgsgQKZ@A⊃SH@A9←h@A!CmJ@AiQSL~∃aCIiSGk1CdAM∃Cike∀\@@A]QSYJ↓I←S]≤@AiQ∀A←SXAgaS1XAiCMVX@A]JAIKMSO]K⊂@AiQ%f~∃i=iCYYdA]Kn↓[KGQ¬]SgZ0AC]H↓S]G←Ia←eCQKHASP@AS]Q↑A%→0\@A)!SfASLAC\@↓KqC[AYJ~∃=LABA-S]H@↓←LAG!C]OJAoQS
PAiC-Kf@A5S]ki∃fAS\A%→_0AC]HASfA%[a←gMSEYJA←d~)CoWo¬eHAM=dA[←MhA←i!KdAY¬]OkC≥Kf\@↓≥←iJ↓iQCh↓iQSf↓MKCiUeJASLA]←n↓BAaCIhA←L4∃%→_ZZAgUEgKcUK]hAUgKef↓GC\A9←nAkMJAiQ%fAisAJA←L↓S]QKISiC]
JXACLAKCg%YrACL~∃C]dA←LAQQJ@A=iQKd↓←]KfA%→_ECYo¬sfDAAe←mS⊃KH\@A/JA∃]mSg%←\@AI→_Ao%YP@Arowing -- largely through additions provided by its users.
Slots are another type of representational piece. As with inheritance
modes, the information relevant to each type of slot is stored in a unit.
The unit below shows that: The value of x:FeedsInto must be a list of
manholes, the only x for which x:FeedsInto is defined is a manhole, and
that if x:FeedsInto = y, then y:FeedsFrom = x (i.e. FeedsInto:Inverse =
FeedsFrom).
*--------*--------*--------*--------*
FeedsInto
Isa: (AnySlot)
Description: The slot naming the downstream manholes.
Inverse: FeedsFrom
HighLevelDefn: (Composition OtherEnd ConnectedPipes)
MakesSenseFor: (AnyManhole)
Format: SingleElements
Datatype: Unit representing a manhole.
ToCompute: (λ (u) [Find the pipe, P, to which this manhole connects.
See which pipe, p', to which this P is connected.
Return the manhole m, which is connected to
pipe p'.]
Note - the ToCompute of a slot indicates how to deduce its value -- i.e.
S:ToCompute is a function, F, whose value, (F u), is the value to fill
u:S.
*--------*--------*--------*--------*
It is important to realize that those facts shown above are not JUST a
description of the FeedsInto type of slot -- it really is used to define
this slot. If any of those slots were ever changed, the way this slot
behaves would be affected. For example, resetting FeedsInto:Format to be
SetOfElements (rather than SingleElement) would cause RLL to redefine
FeedsInto:ToCompute to return a singleton list rather than a single atom
(corresponding to that manhole,) and to (retroactively) fix up each value
of u:FeedsInto. If that value were empty, it would remain empty.
Otherwise the single value v would be changed into the list (v).
Similarly, each data structure -- each rule (condition/action heuristic),
task (small local goal), and agenda (list of tasks dealing with a single
topic) -- is stored as a unit. This permits the data to dynamically
altered during the course of the computation, or through user input. That
is, one uses the same procedures to add in a new unit, independent of
whether that unit represents a new rule, a new pipe, or new type of slot.
Even the procedures of this system are encoded in units -- notalby
including the parts of the control structure outlined below. As with
parts of the repesentation, these facts are actuallq Used as the system is
run. Editing the units describing them will result in changes in the flow
of control of RLL. Fop brevity, we will address details of only one of
these chunks -- the rules. Section 2.4.1.4, which overviews the contol
structure actually used, will then sketch the other parts of the system's
control, emphasizing the advantages which come from "unitizing" these
parts.
!2.4.1.2.1 Example - How RLL Encodes Rules
Each rule has a number of obvious attributes. The primary fAcet od each
rule is the actual code which iq to be executed. RLL spares the user the
arduous task of enteringthe actual LISP expression to be run; instead the
user can type a more laconic high-level specification of what this rule is
to do. RLL then "expands" this definition into that Executable code.
(This iq done in a very general, RLL-ish manner, using facts stkred in the
name od the slot,∧@A⊃∃]GJA%h@ASLAiQJ↓k]Sh↓Cgg←
SCiK⊂AoSi AiQJA)QK9)KYYUgKd~)gY←h↓oQSG @EW]=ofDAQ↑AKqAC]HA∧A[KgMCOJX↓YSWJ4∀PE <A]←h↓EeKCQPAiQ%fAGQ∃[SGC0X@DA
QK[S
CX@D∧BD~∀DA∪h↓Sf@DQ)←q%GSir↓πQK[%GCXRD\DR4∃S]i<AG←I∀AoQS
PAae%]ifA%hAoQ∃\AiQ∀AkgKHASfAAeKgK9h@ZZ4∀Q!%=∂≤∩Q]eSiKQ←+gKH@E ↑↓]←hA eKCi AiQSLAGQK5SGCX0@D@Q≥Ki-C0AπQK5SGCX$@DBBλR~∀∩!/eSi∃)←+g∃d@DA%hASfD@Q∂∃i-CXQ)←q%GSir↓πQK[%GCXR$@D\D$R~∀R4∀~∀T4ZZZZ4ZZTZ4ZZZZ4ZTZZ4ZZZZ4TZZZ4ZZZZ(~∀@@↓%kYJ ffd~(@@@@↓∪gBt$∩Qβ]e%kYJ$~∀@@@A KMGeSaQS←\t%)KYX↓iQJAUgKdAQ↑AQ←1HAQSLAEeK¬iPAS_AiQJ↓GQK[%GCXA%fAi←aSF\~(@@@@↓∪M!←QK]iC1Ys%K1KmC]Pt∩QβA!→2AQ←qSG@AπQK5SGCX$~∀@@@A∪MQekYsIKYKm¬]ht∩!β!!→dA≥KCIEs+g∃dAπQ∃[SGC1⊃Cg'∃KaKIQ↑R~∀@@@AQQK])∃YY+g∃dt∩P ↑A]=hAEe∃CiPAQQSfA
QK[S
CXX@λAπQK5SGCXDBBD4∀∩∩∩DA∪h↓Sf@DQ)←q%GSir↓πQK[%GCXRD\DR4∀@@@A)QK9βII)=βOK]⊃Bt∪ 5KeOK9Gs!e=GKIkIKf~∀@@@AAeS←e%irt∩%⊃SOP4∀@@@A∨])¬gVt∩$Q∪[[%]K]i⊃C]OKHR~∀~(@@A∪5[S]K9i C]≥Kd~∀@@@A⊃KgGe%aiS←8tA)Q%fAiCMVAie%KfAi<AMS]⊂ASLAQQJAGUeeK]PAgSiUCiS←8ASf~(∩@@∩$AIC]≥Ke←kLvAC]⊂ASLAM↑XAgUOOKgPAg←YUiS←]L←MSq∃f←CYQKe]CQSmKf8~∀@@@A∪g∧t∩@@!β]s)¬gVR~(@@@@↓%kYK1Sght$@@Q%UYJFfLdX@\8\R~∀4∀@@A∃[KeO∃]Gs!I←GKIUeKf~(@@@@↓ KgGISaiS=\tA)!SfAi¬gVASLAGCY1KHAS→LAiQ∀AGkeIK]hAMSikCQS←\A%bAIC9OKe←Ufv~∀$∩∪C]⊂ASggUKfA[¬]rAcUSGV[¬]H[I%eirA=eIKeL\~∀@@@A∪MBt∩@Qβ]sQCgVR4∀@@@A%kY∃→Sghh∩@@QIkYJFdpbX@8\\R~(~∀ZA9←iJAQQJAeUYJAC ←mJA%fAoQ¬hAiQ∀AkgKHAo←k1HAisAJ\~∃I→_Ao=kYHAUgJAi!SfAi<AG←[AkiJAQQJAC
i`↔πbβS=7⊗)7KWrβ∂?∪*aβπMεKQβ←∂→β;↔.#↔⊃8hQ)55ji555jQ555ji555Ri555ji55)ji555ji5(4Ph*S#/∪∃βπ⊗)βO↔6+Kπ1εkπ+?∩↓βπ∪6 ;Sπ>+MβSzβCK?6K∪';:β ?SB↓β#'>Aβπ;"β3?]αβ3↔[.`4+≠␈∪7Mβ}1β¬β↔+3∃β∨β↔∂'6K∂πSN{99↓αα'9β∞#∪'SN{9βSzβ≠π∂Nc'Sπ&K;≥β&C∃↓β∨∪↔πSN{84+}1β¬βv+]βK.c↔M1π##'MεC'∨#/⊃β3↔6+1↓βn /↔Mπ##∃βv SWK*β?→β&C∃βK.c∃β↔∂≠'↔IαβS<4W+;∪↔↔≠Sπ≠"βπ;⊃π∪↔πO}q↓βπ⊗{WQ1∧3?Iβ⊗{S!↓π##∃β/≠↔Iβ∞s⊃↓α∀b1β''≠↔3→r↓αJ2b↓β'LhSπ 3*βS-β/≠∃β∪N3≠↔K.sQβ[/∪G'?w→β?→¬##∃β&+≠';LεFN}d
v $≥~→$∞≤[xl\≥<Y$
|Hλ∞=≠⎇β!,[|@ M9YY.,;]λ∧∞≤<⊃$
yHλ∞L<z|eDλ~;D
=8r∧∧≥~→$∧≤x;,T≠8;Ml<Hλ∞M_=⊂λ$w:2\&4yxβE0λandhes bothcompiled And interpReted↓IP∨Ko→β/→∧+π∂!ε3W;∂&K?99ααW#↔pβ¬βW≤∧W!"]z.≥→<h∞MβP2l_vtw2H7y⊂ %dit @∧@AMk9GiS←8XAβ_↓akIYLAS\Aβ##πQ∧3W;∂&K?9∨~↓βO?/∪∂∀4Tc'OSNs≥!β⊗ S#↔⊂∧π&F≥`αε6},6*πM Rπ/<X D∧≥≠h∞ <]0→YP& hλ⊂1w`$e* Howevep∧AShASf~)iQChαβ3/]nc↔[↔bα2εA∧∧6}&T∧π>F≤=α∧LDλ⊗∨'\≥FgJ∧
'.w5`α¬≡≥]⊗f∂-O∩π> Ybαπ=⎇V.}lQPW>≥nG~πMtε/F≥]⊗v* ⊂π↔.LUBαF≤Tε/∨M≥V∂&T
ε␈:
Mvv:
≡Bπ>≥MBπ&≥<Rbε}$αε&↑LW⊗N≥lPhW⎇ ↔"π=}''~∧
v $≥~~-l|hλ∞M~<h∧ >→8n↑~;{D∞z;≠∧∧_9YL\⎇
$∞~→(∧∞];⊃$}hλ⊂m⎇Xz<lQ HY \{_<L≡~=Y$$→[p→≠P7s⊂≥42P9\2qts~qpz4[w⊂⊂4\P7s3→y2rπλ⊂*44\T⊂7cλ1wzy≤rV⊂⊂~yFE'∪j⊂:4→P37y≠P⊂;t~qt⊂4\β actually run. The much-less-perqpicious expanded
fh∂eZ↓SfAkMKHAM=dAiQ%fAakIa←gJ8@A)Q%fACYM↑AeKAeKgK9ifAB↓gSuC YJAg¬mS]OL@A←L4∃ek\5iS[J↓gaKK⊂\@A'∃GiS←8@d\h8b\j\LACIIIKggKLAiQSLXAC]⊂AeKY¬iKHX↓Sggk∃b]:~(~∃)Q∀AKqC5aYJA¬E←mJ↓gQ←oLAQ←n↓iQJAMaKGS→SGCi%←]fA→←dAi!SfAeUYJACIJAgG¬iiKe∃H~∃C ←khX↓gi←e∃HAS\↓gKmKICXAI%giS]
hAgY=if\@↓)QSf↓aKe[%ifAI%MMKe∃]hAa¬eif@↓i↑~∃ JAKq∃GkiK⊂AS]I∃aK]I∃]iYrZZAM=dAKq¬[aYJ0ACYY=oS]N↓iQJAEkSGV↓∪M!←QK]iS¬YYr~)GQKG,Ai↑AIk\@AQ↑ACYrules; and then running the more
expensive IfTrulyRelevant part only on that small subset which passed.
The THEN parts are also split up. In common practice, once the IF-parts
have all passed, each of the THEN parts is run, in the appropriate order.
The description above is the way a rule is evaluated "by default" -- that
is, unless the user has something else in mind. Recall any user can
readily modify that rule-evaluating procedure as well. So, for example,
the user may decide instead to execute the code stored on the
IfWorkingOnTask slot of a rule, or IfTodayIs, or any other Set of slots.
rather than the current IfPotentiallyRelevant and IfTrqlyRelevant slots
now used∞ In getting EURISKO rqnning, Lenat had to deFine three a`ditional
ru@1JAS]QKeae∃iKef↓←L@AQQSfAM←ehXAiQ←UKPA[=ghA←_@AiQ∃ZAeK→Kd@AQ↑AiQ∀@AgC5J~∃W%]Ig←_A∪LZ↓C]HAQQK\Z↓gY←iLA←LAIkYKf8~∀4U##∃β/≠↔Iβn e↓β∞cO=β&+∂'∪*βS :∧λ6}o
z6*ε∀λ m≥Y{⊃$∧∃≠⎇ ≥ 21EZ_<]¬D≥z~,=λλ⊂)h≤c"NMβsrj~2y⊂ !lh oF the difFerent ty`EpεA←L↓∪@→7ε CCMp∧αα¬=_ -≥_<[∂∀~→(
\>(λ∞|;]β!.~→(
I⊃3@∞ <X
9H2|2q]z2r in a↓ISMM∃eK]h↓←eIKHp
β?⊂β7πeεCπ[∃ε#↔∂'&+⊃βSz↓β?;eH4+K,¬bπ&
z6*¬IλT`$≤_<NNh→Sn⊂;t4Xt⊂42H40yP≤zs3 )cient res@=keGKLXλ4!Q$f@⎇→(∞M_9⊂≥44qP_wzv"λ53r be done Id∧AKC
PAeKαc∃β←,ε&*π=_ .
≤(⊂⊂H9tw3[2P⊂(~pqrFB4πf @
←[aSαc↔" 8 lL+λ⊂↔\α only a @⊃←kEYα)β#Wo↓β >dλλm|α2P∀∩c⊂0w→⊂*$"Sα). U`
AGαcπ'\X ↓QX8[nl(≥~ ≡λ~0~λ8πa`&AKC@≥IβC=∧∧6F∞βYy$∞~→(∧∞];⊂∩H4w:2\αpre@QKd\@↓)QSF↓Sf@A KGCKβ≠∀4.Mε∂" -F}≡4∧ε}Hλ⊂⊃[p∧e is i@Q`∂.β→H∧ 8π⊂⊂∀& un`∪Hαq↓αM_
lTλ≥~ Tλ≤]-L<kλ∧
=λλ
≡c"P∩→qwvx≠yrr into nice si`5α+⊃β∂G+;/Mbβ←#'≤¬ααε<≥bε⊗Tλ
-l→<⊂∩[22w:≠<P⊂ -o`if@%K@@8hR0≡vTλ n\zλ⊂∀≠wuP )pε@ABαβ3'O ∧ε}Hλ⊂→[4πtnam` fAβ;#'∂@∧ε≡}n8
≡≥=→$∞~→(∧ 1H⊂__y:⊂ /d∧@AB4⊃ekYα)1βS|∧v/& X D∞z=~∧ (λ⊂∩→yqy4\:4wgλ4πf @]QK@9∧εFF∂D∧ε≡}LTπ=≠⎇3 D_Y(∧ >→0⊃]z2r.
We wi`→X↓eKikβ∪9↓β&yβS#M→↓βC|K;QβLqβS#*↓β;↔G!βO↔≤εFN}eDαπ>
_λm∧→~<l><|q.P⊂:4→FA10\βic Control structuRe.~∀4⊂TZZ4ZZZZ4TZZZ4ZZZZ(ZZZZ4ZZZT4ZZZZ4ZZT~(@@A'QC]ICII%kY∃∪]iKβ∪CK↔&+H ($∧ααα ≡6 Pα"*λ≥↑4]-L2;] ↑\≤Y.L<J#!$λλλ∧λ→<xn
<≥~-⎇NB5
<h~.P:42H9z0w→0y2≤97qrY8y2P≥yrr tk iNterpRet a eiveN
∩∩$@Aekαc∃)↓∧KQβ≠Lε'∂" [ε.∨↑LW
πM R∧ hEVW∞l8
≥{H∪l@⊂:42H9:v %'s
If-Parts. I` Ai!JAeKMkYhA%bA]←9→∪_X↓ShAKaKGki∃fACY0A←L~(∩∩α@↓ecYJ≥fA)Q∃\[!CIif\~(@@@@↓⊃SOQ1KmKY⊃KM\t$Q∪ @!β∃λ[)k]Gi%←\A!I←GKgM!Cehαα'~C∂∪SM$hP$$%α↓↓↓" r⊃6+.s∂S'}qαCK}≠↔ONε KQα&C↔:C∂∪SM%Hh)↓↓α↓αWO," fK.c↔MhJBKW3*→MαK.c∃
Uαq99$hP4(4R↓↓α'5βπKS_h)↓↓α↓α'O P$%"∞sfO3␈!$4)α↓↓↓α&+O∂KOβS'?sP&S#*β[π3,)β?→¬##'Mπ≠3?QεKEβSF)β3'∨!β/→π≠3?S~β?→β&C∃βWvKP4(HH%↓↓FC↔K∃ε βKWd∧RJπ⎇
⊗≡B LW∞≡]lBε7-⎇Rπ& Tε≡f≡8 eD⊂;↑)≤T_<NEC"B!⊃(λ∃
<y( ≡Y(∪n,→<Y,D_↑(∞M→(≥L≥≥9(
|H≥~ ]<H∀L↑|→8nM=Y#!!""(∧ |Y→.([xTN]→4_..≤kC!$λλλ∧ ~9z L=Y3λL9[NA∃∀≥= ≥S|Y ↑H
∀n\\y5∞M;Y` ←4{≠nNhβ"A⊃"""!∃∃X;∞\2;XmN9→<d <x(λ≥↑29J <]
%⊃"B"!⊃(λλ∧ |Y→.([|TN]→4⊂⊂\:9TFB⊂⊂⊂⊂λ&pur\irw9Yc7y
αi:v"\FE⊂⊂λ⊂⊂"0]0z<h→]∧Di[7z9FB⊂⊂⊂⊂λ#7y6Xz≥∧DSβrderedSetOfElements
¬
Simplified version of the Standard Rule InterpreTer.
Much of itq code is "hidden" In the parts of the HighLevelDefj -- eg
IF, AJD-Junction, ... Of course, these too are units, and↓CeJAYSgSE1JAi↑↓iQJ~)S]iKIKgiK⊂AkgKH\~∀QQQJA∪→!CeiLAkMSβ!β'Mπ≠#?←paβS=∧∧FO∨>\⊗&*∞Mε␈≡T
vFZ Mrεv}@ε⊗.M_W6*∞MεO~ =F∞NUa⊂hR%URjjUQRjRUURjjUURRjUURjjUQ"jjUURjjU!PPH!Q$⊗.mz&*α
HV∂6≥lrαα∞MεO~∧
'.fT∧αε&↑<7εO∞M⊗}rD∧απ& Z&*α ≡&*α∧∞6/6↑,⊗bα∧
w&F↑!PR⊗LX6f∂,≡FO6T ε ,8⎇≤d∞z~0⊃Z⊂⊂6tYβht Be s@Q←eKHαβ'9β,∧⊗≡B∧
'.fU`α∧}lTαεN↑
wπ_;]↓Q\{∪nD~<h∞M→(_.l<X9lTλ⊂t
T≥~3,T≥~~.P⊂9:[2P40\P9x"[:⊗⊂⊂→4πr ExecuTing its IF
pArps and TH@ ≤@↓aCeILX@Ae∃gaKGβ#'[↔gI9↓↓¬##'Mαβ∂π9αβ ∃↓¬+Oπ⊃αβ∪ ?$∧π6∂-→w/_Q)V/&∃]F/6]Dπ⊗.≡9vvNβY`⊂≥0yuyH⊗VP⊂≤zqt_yP22Xtr4w→β whetheR to Even cons@%IKd~)iQSF↓` @.LTεNr∞Mε*εnX
∞↑Y(
≤αP24Y⊂4z9H10w3H5:y`4iby @%ifAEUGWfR8~∀4T+π∂!∧ε'.fTλ⊗g≡t∧πε.=x LNhε⊂ )n a qlot the h
C[∀AP∨→∧KSM↓∧ WS#|ε"ε@|Hλ >Y8=
}Kβ"N⎇~8p∀λ4¬`∪O!hAEJABAaα+@↔≡⎇`λ∧ 9Y⊂≠tst:λ12P⊂_w0∂ther rule (p¬k@3-→β∂πp∧αεNn>ε.∨EAPFNβy~,@<V⊂ !nd SynthepπSuJAWiQ∃`@AeUYKfR8@@A)!Sf@Aα≠π9↓∧¬ε.g∧∧ε&.=_F*α∞⎇εzα∞MphV>,V&OExλML8εrP→4πr @≥←←H←α∪π"∞.Vf/50λ ≥Yλ⊂~~4yP"_z0P #an help the o`-∃` πMDπ?<⎇→-Q ¬:7H4vx)≠{2P )ts p@∃` ≠∨⊗kπ;∂*β eβ⊗+3g≥lrαε]x LT_;Y∧
9x 2H5w⊂ #apable ⊃i!Ch@AαK@~@β"P→]qqr`3q`
kX$AekYα)β@?-_
↑\k@⊂λ ε`∪]¬YQ`%bβS#∃αβWO↔⊂∧εFN↑8Vf2 8λ-d≤⎇≠n (_;O∀λ≠p~~2yεE≥<x2P≠pε i@9H ?-\↔&Nβ{@⊂~2P;p[8∧s -- theq`
ACIJAUKMhAiQ%]OfAβ;#'∂@∧π>(→P∩Yv⊂6p↑P12FB8¬se@→kXAieaKfAα{⊂∩π>L↔&O>M⊗∨~βC"AQSyH =⎇<\lT≥X<M≥⎇<h∧
8π3 %p¬KMGα)βO∂F+7/4∧αjJ
]w>λλ⊂∀[x7q:_w:6 9 af in`⊃Kβ∪'Sπv≠∀4 FK↔Kπ⊗≠#e↓hiβπK*βWO↔ ∧π&@h≤r-↑≠~0∪≡P20z_P⊂2`.try.AαA]∃nAekαc∃β∂∞qβ ∃αβ↔;S,ε&. Q(λO∀≠90→→v8 @
←a`'Ns⊂~πM ↔"ε←
↔∨&≥lrππ-x
}≤8⊂∩K⊂0w2λ1t0w→βi`≥Nαβ?;O∀π&F|∧q$ 9]≤M≤αyFE≥t4qdλ0y2Pλ4p∞appr`∨Aβ∪'πS*q↓α X L<αP⊂ 4he bulk @=H βSF)↓βC⊗{C↔K&K↔Mβ∂∪∃↓β≤¬⊗oεLε#!4p∞hep¬SiKα!β≠K|iβ .|∧Y$ y;Y.0p @%IKCFZP∃βF+@⊗* h M⎇(⊂ &∪⊂πs @→CGif↓CE@?,εBπ↔]H .P⊂4`.
ge@9KeCX8@@@(hP4*@8h Mm⎇→*G⊂⊂$gλ30q`4, fo@HAaKI¬O←OSα→βK↔∂≠?;Mb↓β@>Tλ -≤z≥⊂≠pp e the Novac@∀@Akgα+@⊂@ ¬6p\z2y ondy a smalhλAgUEgKhαβ?2∞Mε*π=H nNh~3M≡~8;
O(≤⊂→→yrw:λ4s⊂)∪&∪⊂⊂∩2P72YrεE ,earnabge@PAWiQ∃`AIS5K]gSα{;Mβ|1αJ2b;Eβ↔G#↔;∪∞∪'3''Iβ?;eIβ←#,qβ#∃ε∪↔∨'w→βS<hS∂?7εcπ'dλ⊗⊗←↑@λ
⎇h⊂⊂]u{py→⊂4r⊂~yP:7H⊂2w1[p2P 4his Op∧AiQ¬hAMC
hXA←β⊃↓β←|s∪↔K_h#←#Jβ#∃β≤∧⊗r?D∧π≡9; ∞MβP1`\8:y2H⊂9wvYP80y≥4qzf_y⊂:<\2P⊂'Y⊂4r2XTε Until that
tiMe, For Exaeple, he need have ngthing more that a "behaviour
αdescriptign" kf The rule InperpreteR -- Which is alh he wouLd ev@∃` ↓β↑s?\4V ?W"βS#∃ε≠?KK/≠C?;&K;≥β/3π3W∂#?IβLqβ7?≥!β?SF+Iβ↔Gβ↔KQπ≠gOS.kM:@QQ hUM Rε∞-}f*α LW<|Z<∞M;{@∧
yH∀N]→<h∧
;≠≥.>≤X= ↑hλ∃
(→→,}Y9(∧
yHλ mα2|4X4v4j≡FE0{_tp able to the user at The deqigning stace. The current RLL includes
many rule interpreterpεAoQ%GPAo∀XAiQ∀A%→_↓IKgSα;;↔K~aβ≠↔g!β←↔⊗)↓βπ∧επ⊗␈∞-⊗∂&QQ&∞vD∞W≡.nYB`$λ∩5∧
<h~-↑≠|] ≥]λ⊂~≠P⊂92Xv4⎇"K⊂47kY{2y⊗λ:40zλ:42P→{2w:≥pv⊂⊂≥yryεB4yP7≠z⊂64[tz2rλ⊂:7P≠w6<Pλ:42yYU⊂⊂'≠z⊂⊂'[6<P4\P42Pλ392rH:7P⊂→2yt`'n his own
anterpreters, but RLL aids in this miss@%←\X@↓ErAaI←mSI%]N@AQ←←YfAoQS
P~¬M¬GSYSQCiJA
←]giIkGiS9J@AgUGPAS9iKeaIKiKeL\@@A%]IKKα!1βπ~↓βS#/≠∃βS}{3M↓ε K∀4Tε&/π,↑6.wL\BεNd
$db ≡2π>]IBbπM Rαπ↑<Wαε<≥bε/lX D {{\nN]8⎇∧
~<h
}{Hλ .:;→
≥Yc"L≥9≤k∧
9H~ T→Y9-Nh≥~ T≠Y1,EC"C!*~→<LT_<Y$∧≤z;-≥_<@∧
98z ≥Z<{.4→[tD∧~;<
L;9;NM;Y`∧∞~→(∞∞[xy.>y<h∧∞<y1∧∧→[p→βE⊃1:[74w3H⊂0sr[20rVλ7y⊂⊂≥0yuyK⊂7y⊂λ7z42\⊂1w`.trol regimes. (For examphe a
black board architecture, fh∂dA=iQKdAica∃bA←LAiCGα[M9%ααπ?K⊗+GC?v#';≥αβS,4V+π∂!π≠W∂!αβCK?≡+@∨~
~2απM Rε&≤L∩απ>N'.∨NX LT≥≠h∧∞z~0⊃Z⊂4r⊂λ0x8 ,ias 6↓C]H@↓%→_~)S]GYβ+∪↔Mεk↔π;~↓β≠∨⊂∧αε/-(
Ao!K\Ai!J~∃kβ≠↔Iβ>KO#↔~βS :
]v&No∀εFO4∧ε/F≡>FNvtλU~R∧ ε/⊗T
FF*∧∞W≡∂$ ε∂~∞Mε*ε}∞FN}d∧ε}0Q(6F∞l⎇⊗v:
↔
ε]→f"εL≡F/∩Dλ⊗v"
=f␈:∞Mε∂"
)Dbπ⎇≥Fbε]xFN7∀λ M}λ≠{MO(≥~ Tλ_p↔Y2VεE_8z⊂ 0erfoRm the retroactive updates to His data required to k` K`↓G←IJACMH4∃ICi∧AS\AMs]GP8~∀
∀∧d\h\DXd\d↓%→_OLA≠←I%MSCE%YSir4∀~¬ %MMKe∃]hAgegiKZAQCmα)β∪'43↔K↔w!↓β∂|¬g6.nM⊗}w4 F.6≥m⊗v:∧∞vF∂D
ε∂↔D∧ε}2∧
FF(Q( N][Z0↔→P⊂9|\z2v@ is changable, and which Iq, To all but the most
sophisticated user, untouchable* By design even casual usep¬fAG¬\@AK9iKdX4∃GQC9OJA←H@AIK1KiJ@EI←[¬S\@A⊃CiBD@ZZ@↓MCGiLX@AS8@AiQ%f@AG¬gJX@↓CE←kP@AiQ∀~∃G←9]KGi%mSir↓←LAa%aKfXA←dAQQJ@AAeKGSMJAaY¬GK[K9if@A=HAmCIS←kfAEkS1IS]OL\~∀Q∃JASLAiQJ↓kgKdAYCi∃d@Ae∃CYSu∃bAiQ¬h@A!%aJFh@lAeK¬YYb@↓UWS]∃H@A!%aJFfDnX~∃ICiQKHAiQC8A!Sa∀Bfbl↓CfAQ∀AQCH↓iQ←k≥Qh\R4∀~∃∪8A[C]dAeKaIKgK]QCiS←9bAgsMiK[f0@AiQ∀AkgKHAGC\ACIIIKfAC9HA[←⊃SMr@↓OK]KISF~∃=EUKGQbACf↓oKYXZZAM=dAKq¬[aYJ0AeKgAKGSMdAoQS
PAMK¬iceKLACeJAoKYαa7∪↔4K;↔⊂hS≠ ?$∞GOε↑4ε}2∞-v∞≤kλ
}H≤Y,NX=`∧∞~→(∞L>≠{M⎇:8x-D~;YM}Y8=
≥{H_,-⎇=λ∞O<→4d∧≠yC!-z; D∧∩;H∧ 9→~.M;{H∞Mhλ∃
<y+∧∞{{9$∧≠_;L}89y.∀≤→<M]=λλ∞M→(≥.<<Hλ∞Mhλ→ \Z;Y!Q]≠⎇ ≥≠≡(
l=h∃∂≡→<h
|Hλ≤L]_=~-⎇\h %T~;@∧∞~→( m|[(
|H≠Y.tλ≤s
}≤h→M}H≠⎇.$λ∀S A"[_-l⎇89lUHλ
λm|H⊂∩↑0vx6→V⊂:4→P#2rY9dw:≠P⊂9f≠z⊂;t~qt⊂+XyP40[24v<H22s$[2r⊂⊂_yFE*~2P!w[x7yt]4ww≠q⊂:4→P'p∀herEnd andthe ConneCtedPIpes slots.)
Thes@∀AIKMαK;'SN{;Mβ≡ 9β *βWO↔ ∧π&Z∞,V&.m≥f*πM Rα⊗\Xλ-m;Y`⊃λ5s⊂0H9v7zλ0yP⊂≥rv6εB0yP4[4z4p]2P7`.e( @AMkaa←MJAs←TAeKC1SuKHAiQCPAaSa∃bAG←UYHAe∃CYYr↓QWS\A[C]d~∃aSAKfXAICiQKH@AiQ¬\AUkMh@A←9J\@AQQSf@↓o←kY⊂AEJ@↓ISMM%GkYh↓iV@AMCrASαq↓β7∞sd4+f ;∨W∞;↔M↓jiβ';&+↔⊃β&C∃β?vceβO|cWS'}qβ'9εk?OQ∧k'∨#"βK↔G,KK∃β&CK?←Ns≥↓β∂;πd4U##πQ∧3↔↔∪≤K;S=∧c';-ε ;⊃β&+≠';Ls≥⬬#?Sπfceβ;/9α≠↔,#N';&zMβ3Ns-9↓∧+[↔9¬##↔8hSπ31ε{→βSF)β↔cO≠S';8β∪πSλβ←?Wf!β#π4∧Rπ&t &*πN,⊗w≡lZ&."D∞&.?,↑G&∞-O∩ε↔∀
ε∞vEaPPh)→b¬∀IEBε}d
FF*
zFF/$∧εF∞lABε∞MDε}∩∞Mε*α X∞ \⎇=_,-→(_m|→(~.P6pr→P⊂2l≤64qt]⊗εE0[2⊂:4→P:yr\α is permitp KH↓iP≥βn{∪'≠Jβ'Qβ&yβOWO!β#'~β∪↔OL∧vrr∧λ⊗fb
Rεv\XBε&qQ&O~ \FO"∞Mε*αλlV.'9≥g&Z∞]fO"βλλ ←_;:-l(≥~ Tλ⊃_.L=≡0_→P9v']⊗⊂⊂7≠z4q`% it qay`&4⊃'S]≥YK Y∃[@↔≠"aβπ≠ β∂#πv;∃↓β&CπQβ&y↓βK. ⊃αO,εDn∀]HVn∞nN2bαλ≡2αε Tε/F≡N2απM PhV\M↔&@|Kλ
)∪λ⊂⊗XuryPλ:42P≠2qry\py4Pλ1t0w→pyP0[2⊂0v≠⊂⊂:w~z9S@ FeedsInto slo@Q` 4+>K3 "
Iv}Z
H
-≤αP9d[3v2`4on sets$ @¬]H@A
C\AQ¬mJA[UYiSa1JAK]QaSKf↓C@∪∪.!β?9αβπP4V ;eβ&K7¬8hP4*π~β←¬β,∧↔εf≤X D∞≠z3NL9λ≠n↑ λ∀IIλ≤∀M}Z9→.P;0y~wzyP≥4πolS fgr↓`∂W∂@βπ&≤λ
≡~;sN1"K ⊗H37y example, The hidπP@Aαc↔[↔bβ@∨ε\8
,@4qpz~ww⊂&_w3zpYpP3 /p∧AMk9GiS←9fP@A¬]H~∃QQJAkMJ@A←α1βπC∧ε&␈π-_↔&.O∀αε≡∞]fNNβY`⊂≥42P⊂~w7{v→p∧ge. These are The same
thingpεAoQ%GPAaβ∪?[↔ βG=β/≠↔ Wbβ≠/I∧≠?;O'∪W∂SNs⊂~ε|dπε∂,¬≤d¬+(_N↑λ~5∧
<hλ ≥≤{c! Y(→/∞≠≠r.L9λ⊃M}H≤Y.NYk8,>~=Y-O(≠;lM9↑:-lh→>
≡⎇~;LT≤_<NNkJ(∧
S∪ n∀λ≥;M≤[|[!Q\Y<∞,<y3NL=~3md≠yH l8⎇≤d
8:y.4λ_z ≥Yz;LT≥~→$ {y→$ <hλ \<}( ≡h_;∞L<Z;Ltλ_;O⊃"Y≠m\:;@ L=_(¬U(_<d∞~→( @0qz9H;t4`#h sp@∃GSMSα+@~ε∀
6f␈D}2ε∂-~GJε≡4εNr∞Mε*α∞<⊗n(β"QM}Y8=∧ <h→ ≡_(⊂⊂X7zz⊂∪βi`_FLbPA←H@AC]dA←iQ∃dAI←5CSLA=` βK/βK↔O,sSπSL{9↓β6 ∂Q_hR≠GK&C↔K7⎇∪∃1↓¬∩21∨~↓↓ Wv#↔KO& ;∪'v9 ↓β|∧bαπM
⊗v?4∧εfN<Tα¬≡≥lvf,]HVn.β]λ∧ ;Yβ!*y=∪lH;→;,]]≤h ≥≠≠unP4z⊂≥5P27H0r6⊂≥42P0\897x≤4pz2H30|2\T∧ automatically.¬
RLL extends this modifiability to inc@1k@∪∃¬##∃β≤¬vw'-yBπ∨N.V∨'↑,Rε∂4∧π>.ME`hUM
↔~π Z&nON4π&FT∞W≡/$λ
tλ_p↔[9z9:Xz⊂44\P7{wλ33y6H⊂7s⊂_ww:9≠v⊗⊂ \P42Pλ72rb≤FE4j α
The next secti@=\A←kQYS]Kβ→↓βSF)β∂?w#?1β≥#C@.>NW⊗*∞|Rαεmx
-lλ≥<l\];λ m|Hλ∞M~8 FB80y:~qzv0\⊂'tfλ)x4f≠⊂:0yZW⊂⊂+YP;tyZ⊂:7P→vx40\t⎇2Vλ0spt[⊗⊂:4_z⊂:4~yP⊂ Yrw20CE0
e@
QC]SMZASf↓EkhA=]JA←α1↓βO/3↔Kπbβ∂?;'∪?1β≥#K@.>NW⊗/5Dπ≡}\TεNo
H -\;]→,Dλ_;LA"\sm\(≠9.,;≡( ]]Z0→Zww2rλ⊗VP⊂_w2⊂:~0z⊂*~2P:yYy⊂⊂1[zv2⊂~0{2P→2yt`'ned his Own
@→aWZAM[CYY∃` βCL+∂↔Mπ≠WCCfK↔⊃β↔IαJ2baβWOLs≥βS}{3Mβπ∪↔O↔w!β'9¬∩218hP4)¬⊂qQ9Eq→↓α∂}sSK?`h($*&C∃β∂F Kπ∂&+K'O&K∂M↓ε{⊂∩α∞Mε*α∞↑6/∩|4ε∨/.,Vw"∧ F}n≥≥bαπL≡6Jα∞⎇⊗f@λλ≤nN[{YmO εE$[36:b[1rP*~2P1`(oice of @]QSGPAG←]QeWXAIKOS[∀Ai↑@↓gKYK
hXAo!Ch@AαK;≠↔⊗+;∂∀hSπ3∨⎇∪'S#o→β←'faβ ∃ε ∂S'6)1β←F QβOf{SMβ>K3 " ,Rε.↑
F␈N\EBε/L5bα∧m}"ε/ ≥WεfUAPW& Tε≡}↑
F/&T u≥~
≡2αε←∞ε.∨L\Bπ&t∞ε/⊗m}&jε∀∧π6∂-≤W'J
xbε&≤hf/⊗]nBπ&≡=7~α¬UPhVn-vjεL↑F/⊗]→fNvt∞FF*∞O↔ε*
x D∧≥~→$∞|~3
D≥≠h∞ <Y[n
:;Yd∞X<Z-}<hλ∞,;90∩~pz4w[εE20\uyV⊂λ⊂9zqZ⊂⊂⊂0\P⊂⊂7≠z4s<Zw3P⊂λ:42Pλ⊂0z`4horitias. Another important
characteristic od∧AiQ%fAU←λASfAQQJ@AQS[KY%]Kgf↓C]HA=eIKe%]NA←_AiQKMJ@Ai¬gWf~(ZZAi!JAS[A←eiC9GJA←_@AeK
←eIS9NAiQ∀A←GGUaCiS=\@A←_AMSeMhAoSQ]KgfAIoS9IYKf4∃oQK8AG←[ACeKH↓oSiPAiKY1S]NA!SZ@A9←hAi<@AEe∃CiQJ↓iQJ@↓iP∨CL→β≠Wn+M)↓αα#↔;≤∧PhVLZF/⊗]→fNvt∞FF*∞MwFN=≡GJε|dπ&FT∞f∂ε}.2π≡
}Vf" ,Rε}d∞ε∂⊗≥]w.wD∧εNo
x NL9Xp∩KεE2y\2qtp[68 When The lEak mieht be near pEople. A well strucTured agenda¬
Seeeed ideallq Suited to thesE speCifications. The agendahas tasks of
vary@%]NAY∃mKYfA←LA≥K]Ke¬YSiR0@AKC
PAUkMiSMSα+⊃↓β↔IβO?n)↓βOLk ?3L∧2απ,\↔≡}n1PW≡
_6Bπ≥_Vf" ⊂εw.\X M≤hλ≤∞-9|Z.O(≥X-NαrP#≠y⊂:4→P⊂:0\uP∞ Some tasks, su@
P@ACL~∃iQ=g@∃βL¬g6}Ni⊗v:
∞Vn∞d∧εfOlX eD≥z3
Dλ~_.l(≠=,=λ~~,]→<@⊂λ894g\αity than p CGα[L4 >C?O∃¬∪↔πO|¬g
ε≤,Rα⊗M⎇f*@=→4MTλ→→-]y|X.
~8h L=_ EDλ⊂<d∧_(⊂~_yuP"↑2qzj→yP it
May add neW p C@≤¬74≥≠h∞M→(_,@rp∞da, ocCasioNally pπkaaαcπ;SNs⊂~π⎇ ↔"π⎇zVf"∧ ε∂6QQ&⊗.]`λ∞M→(≠L←≥λ∃ ≡zh⊂~≠P2|2Xzz2WβE
This Control su@ c@↔∂&K?9↓∧CπMβ&CK↔∃αβ?S#,ε"πε≤∧]∞∃β⊂⊂⊂∃42P &irstASfAβ≠'7Cdπ∩αε⊃Q'∂.α8rd Y:_.m8πr`2 ske@QGPA←α1↓βSFK@~ε|¬P∩\αa`→X↓[@↔∂F ;'Oh¬bαα
Mε*π<Xλm⎇Yλ⊂__y:⊂⊂→wryFB4p∞to i`∨E∀@AIKβ#π'EDε&/<8 M≤X;Yd∧~≠p≠H842`3e c@!k]Gf↓←@→↓∧∧6}→(⊂≠Yy2P⊂→β` @;,ε&∂&\@ ↓QY;Xm|α2r, a`≥Hβae@?≤∧W>y9↔λ⊂*42\β`
@Aα#↔O∂⊗KCC'|¬g4≤y0∩[P:7Pλ4p
p@1rAiQ∀A%→_AP↔W≤εB`@ ¬72Xp¬ss@¬` 'Lε+∧ Y(⊂∀~p∧eo@U`∂3@∀∧π=≠x Gλ⊂*44\β i`&A≥∨(αβS#∃∧∧6∂≡U`λ∧∧∃~→$∞α44`2d p@¬` @ Q( n 8z0∪~qpv ,y addres@MKf@Aβ##∃↓αβ'OO,∧W4λ≠p∪λ⊂9x %e`λ@@↓C]H@↓K@≠≠L∧6N8π1`9 ~Zα↓↓β∧hS@∨.lh
,=9;]
O(~0⊗\4πr`)¬]`⊃⊃∧∧⊗v"∧λ -≡⎇;Y ↑\⎇≠m|α⊂ @A←S@; ∧π&F≤¬⊂λ4z⊂ $eserve`λAi<@AEJ4⊂ 'l8 ∞\α2r in this depπGeSββS'⎇`λ∧
βs⊂)∪&⊂∞ Almo@MhACYαa↓β?2βS#∃∧¬F␈∨D∧ε.YZ0⊃Zp¬`≥GβH4+∂∞qβ ∃∧ε&.≡≤∧⊂~≥y2r.
~∀∧d\h\β 0∪~βHλ@3βvervi` nAα{⊂∩∧≤|Vv&∀ V.≡ ≥fO≡QQ hUM Rε∞|X LL(_p↔[8∧ai@9`
βπp∧π.vβx 2→y2r pπ@↔Q∧¬v $≥_<myP @]QSGPβCeJAββ@⊗@xy0→\β` HAα{;∃↓∧∧↔ @ ¬0@ ti`≠J8@@A& @≡←4∧ε∂⊗T∧ε≡F|∧p∩[⊂⊂10\β` H@↓←\@Aβ##∃↓∧επ-8πp∩ities h∂L@↓iQJ@↓` ↔πα8 mnc"P→]x87`2ti`≥NαβS#↔h¬bα∧\≤6BπL≡6@4~8 P→2yt`'ned @Q↑AaKβ∪⊂⊗@|[<d (≤⊂⊂\αp SGβ+3πIαβ 'S,ε6OVQQ&@-βq⊗⊂≥4π meet alh∂GC0@AO←¬X\@A→←dAKβCπ7Cd∧RbπM Rε>|≥Bαε|dε}vTλ
≡zh⊂⊗X|P12H⊂:7FB22z2\αh @'v)βC#*β[πL¬0∩\β of pπ←[J↓aCeC5KiKeLX@@#*s⊂~@H≥~ T≥_<mP
atType at`)∃[aiKα 4+Szβ∪↔∪αXλlT≥~→$∧≥_ `0e of mate@ISC@1αβ←#'≤¬αεF≤@∂>~;⊂~ ∀P⊂ !nh∂iQ∃` β7∂Iβπ∪ ∧αε@⎇~→.ε@
`)¬`∂/M∧εFzπM
↔4_9y-l_+λ∧¬→[p→λ2|0v\4∧e, the @nds Od∧AiCMP∂Mβ>C'∂!∧εv/⊗T
f␈"
lV≡<|p.∂(→Sn⊂:44\P80y≥4qz`,ar domain-(
@Aα3?H∀T∧WF∞↑ F*b
x LT≥≡0_→P1wj[2⊂9jYpπes@PACMHαβ∂K↔∂#∃β¬∧¬f/: =vv≡↑λ
¬@∧¬
In general, executiNdε@AB↓iCgVα↓β';6{3@6↑4ε&O.8
∧∧_{p⊗≠2qz4[3P92[2{0w≥⊂⊂9:[2yVεB8∧heN orderifg↓C]H@↓ISeS9H
βSFKEβ3M≠Q↓βNqβO↔∂+↔;∂*q↓↓α4{@∩α∞MεO~
I⊗nOLXBαε⎇_ ↓Q\|⊂∀[6⊂8)≠u2qj ⊂:44\P1wf≠2qz4[w⊂9j→x⊂;p\P⊂:9~{4pvλ⊗VP$]⊂;pyH9tvx≠<P⊂&≠wutw→FE:hλ:42P≤pz⊂7Y⊂9:v→yP8 2e)stored on e@¬GPAa¬eiSGUYCdAβ#πO-pI↓αSF+K∃β∂∪∃↓βn ;d4W#gC↔~β?2∞.Vf/5Dε.∞=∧ε≡F≡,v."∞⎇↔&B¬ ↔'&]↑π&Nlpπ&z∀ ⊗≡F≤↑f*ε∀λFN6lZ&.wD
GOεQQ&}∩ ⎇v∞bd∧αDNd∧π&F≡4π≡∞n8Rπ& [∩αε≡,Rπ≡≥]⊗f∂$∧π&@h≥_.≥|kλ
⎇[≡(∧
;H_$∧≤{8-Mα2yεB9qpv→W∀P⊂∀wvrP≤8r2yH2vx ,oy aAW]←]\AiK
Q]CcUJ@QC1O←eSQQZRAQ↑AKm¬YcCi∀@AiQ∀~∃mC1k@∃β|∧bαπ=⎇V*ε≤¬≥∞
8]0~→U⊂⊂⊂
εgbexample, deteRmifi@9JAiQ∀@Ai←aSGSidAP∨→αβ∧4 >K[↔9∧kπS↔⊗Kπ1β↔Iβ3?}[';≥αβ'Qβ-↓β'9αβ¬βS∞∪3∃9J↓α?SF+CM↓∧kπeβ&+∂'∪*βS :∧ ⊗& Q,⊗&&≡M⊗}v≥Dπ↔;→<d∞≠h⊂~~4yP9≥v2VyYz∩⊂ /p∧Aae=a←gJ↓C@∪∪Ns∃β¬∧εε∂↔M_7.f≡ λ
l=h⊂~_yuFE≥4π the agenda.A'iS1XA←i!KefA5Cr@AMkGOKMhAiQ¬hAiQ∀AGkeIK]hAβ#πO-αC'9↓¬;#'∂@h#C#M→βKWd∧W4≠xp⊃]y9TP_2P9z\βpende`$ @Q↑@AC]CShA9KGKgβ≠πKe∧s↔]β& S¬9α↓";∨&)↓βSF(4+≠d¬w:ε|dε≡}]\⊗v"
~2π∂]_
T≤⎇≤N\⎇≥0→→p⊂∞ Eachpqde, pacK kr @¬KC@;& )β∂∞q↓β?vcd4 .3∪↔∂ ∧εO'4λ
-]99~,≡→(∀n↑\[⎇-l~;Yn∃Hλ∪-}Y(→mMβq0vλ1t0w→p¬s Are pEp¬MOE5S]N@↓iP≤4Tε6.vM→f 4≠94n≤9y4d∞≠h⊂∀]9P7{→y27`2d, p@I←a←gαK;≥β&C'Mβ∞cS↔K∂#'?9p¬⊂hPβ"JDλXπwj≠5z2]λ)&&⊂
¬U@%%'↔=J↓β'M∧∧6∂ε≤-F*ε|dε&.≥H
-lhλ⊂≠Zz4⊂)Y{2y0[⊂0sr[20rPλ⊗VFE≤{px 0ing AmongthemACfA9KCHAα C'O-→1↓↓¬##'M∧3π∂'dKSeβ> @~α
yf*ε|dεn∞o∀α¬∀IAPV6\≡G/⊗↑4π>F≤9απy<Y$
Xπr needed fo@HAiQSβ→β+∨⊂p4(Q$∪∩sE` %@→P∞ $↓)QJA⊃KiCSαc@~ε|dπ&FTλ⊗ <8π20H&rqd_w0y`-
~∃]JAGQ=c@∃β&yβK≤X
d 88p∀λ80y:λ5s⊂ 4he o@YKeCYαaβ∂?w#C >D ↔4_(⊂_≤5qr`3q ~Z4∃KCG AWaKβ∪πS'|qβS?|¬2π≡⎇\Rππ,X l>X8Y,D≥≡0_→P7s⊂~w8:`4, and perfor`≠Kα 4+O|¬V*ε≤8
≥{Kλ∞
||p∀X4∧q @IKike9S]NA∧AeKgUY`@8hRπMβ≤[↔S∂F+⊃β'p∧π&FT
πε/m_ n↑h≤p~X9rq`4ion, the "A`∂K]⊃BS!e=G@↔O≤¬w$H≠⊂↔[urr li`↔J↓iQSFh~∀4TK;'SL∧⊗fO,Tβd∞|]f& βC"IM{|λ∞M≤](πJ_8p∃\←≥εEλ⊂#r`4 h
KqP@p∩S∂≠%y1¬ 4)↓¬βC ><X nP*εE∀4πstMorteM 8 βO∃]IB|8~∀4U##∃↓∃#πO-mβC ><X n≥|H@⊂~yP∀7≠z⊂9`5ppriSinglY) si@5SYCDβP4(Q)⊗vOM_λ-M>Y(πJ_8 `+>λ
¬→α{?Aβ&CC@*∧π∀N]→<oG∧¬∀@↓∂@↔Q∧¬f/GDπE↔9→/ED∀C"D∧∀≤[l<αyyP∀∧¬αPOpπi7|ε'&.β(∂
.αp e>,∧⊂∀!Q&∂~
_ d∞~→(
}Y<X-Mα⊂'iTP(97Xp¬ss -
∀~)∪]@'&Kπ3'T∧Rβ@⊂πiiKix `'β#↔5@aQ$f@{|λ∞M≤Y(πH9y0↔→0[⊂~
λ Get ne@ah@yβ≥K]IBβq1α∧hQ↓αC⊗{∂/>4∧λhαT⊂↔\βtEo@IiK@5βb0≥≥5Z7O∨LYSrpβ"C!
~~0→H⊂1w`-monalitp∩@↓oCf@↓H π∂&{C↔⊃αβ?WQb↓βπl@λ∧ >≤⊂⊗≠tz2`$ by def@%]S@;8∧ααπM PhT↑X M≡z{t∞
βqr`3pε@@)αβW;≤@ ∧∧≤z≠n⎇Hλ⊂⊃→v7s@, ac a c@=[[@?p∧αα⊗≥l6/∨Mx D⊂⊂:7H⊂17`4hλ
+αL↔=hεx 2oces@M←efAα ;⊃β∞;↔;∪λ¬Wπ⊗|8 .ywq9H∀0p∪ w` @3b↓βπM∧¬w&F↑ λ∞O<→0→H0p∞dAP∪↔4∧Vg_Q( l@⊂1w`.tr`∨X↓cie@,∧7'<Y(∧¬(≤p~Xt⊂⊂ !pεAiQ∀@A←@4∧W,8ε6⊂≥4πp-level sp∪@≤εF.o4λ M}Hλ⊂⊃≠z4εE⊃zy4`3hπ↑AC9HAiQ%`
αz:2ππ-x
L\⎇_j%@∧¬∀~)0
+≠vs?S∃RαJ2Dλ
l≡h→→.l8ε7h→p∧ as p QJ↓k]IKβ∪C'mm⊗v?4λ M}H≥~ T⊃0
i∩i` O pro@)KGhX4⊂ ∪↔≤∧7-8Y0∩λ4p∞ Xπ⊂∪↔v Q↓α&C∃αl≡G/⊗T∧ε}Hλ∩ ↑<Z0→]4qynKα EURISKO re@1S@↔Mαβ?9↓∧∧⊂hW=x
<⎇~,<=→0∩ ⊂6w`$i`
@'∞∪3∃β∞;↔;∪λ∧εn8z_-m<{ ⊗λ8πhi@
PAS@~β←#@∀λ
.D≥x<d∞α42Pλ30 bstλ
+≤¬vw≤[p⊗λ9z1:Xz:y2H22{ %lh∂aKα!βπl@λ
≥X{p→≤4πrate`λASαsS :λ∧S ETεFEβE⊗V@--(
4Ph ∀∞β↑1.↑X∧p∪@-←!e←α≠↔OLhP&'Oλπ HJλ≥gL≡L≡79βs'`"h¬KGiLR~(M≠WC↔∀≠3πO≠P%"πwJCK|8 .yP
SubClass: (AnyTaskPp¬P∨∂,ε75α⊂ w≡`sr`.daProc` gf0@\\\αH4(_X∞ ≥<≠⊂∩\β:∩Q→kYY U%∪'↔<['`'α8
]+λ⊃N]≠∪tj5αi|`3te`~@8X 9$hP&@'α<⊂∀Xpp E@aC[aYα)`⊂MLε0_~qpv"]y0 `'α[>CK|∧6/∨1Q JReaP@!αE*<\4qpv⊃zy4`3hπ←!e=G@↔O_h ⊂MLε0_~qpv"↑0p
p@1K⊂∨→β$α∧∞β↑1.↑X∧y`+oPro@
Kgf~(∪
k]
iS@?v 2O3|εG7Hλλ¬ ~8 `0Fh A&z';≤M⊗∞f≤εP∩H*7i`%lectNextS@UDA)←aKc'kα⊂4(⊃⊃∩αα∧
F⎇ε|∧p~∪wy0∀em)~∀$X 98hQ5%5h¬PhPβ"Q \β0 ning the tashεAae=G@↔O≤¬w$~8 P≠4πw @→CSeYβIβOSα,⊗Nz≥→M}]x<LDλεV@ d¬Se@≤εBαε>,V∂&QQ'&FT u≥~β0
0\βkProc` ggα{@∩π]m↔"ε≤∧h ≥H→0≤_vx6 % h∂LA¬]s)CMP∞CK|∧6/∨5Dε∞vDλ
8π⊂⊂→αi`→X4⊂ 'dλ
(λ⊂≠_v:r`3 h∂L@↓SifAα3W;∂&K?;πb↓βO3|εG7Hλ∃
y8π4`4ia`→SβS∃ "∧
F⎇≡]H ,>⊂π2`8tSub0~∃)←aKc'kα⊃1βπv!↓αS⎇β?ORn{@↔→; ↔λ⊂⊂λAs we'lhλAgα+∃↓βL¬bε
∧λ -⎇9;]¬D≥~→$∧≥X;∞\αP⊂ /d∧⊂∀)H
.x#7:yP⊂ 'enerated @→` >T∧π&F↑8 $∧_{p⊗\4πne@9if@9ααπM↓∧ε7.≡∧∧π&FTλ
.p¬r is NLπ ⊂4T∧WGε\8
\α⊂:7H⊂2w:→y⊂:4~yP⊂ 6alue.) Actually the u@MKdO@~β∂#?α,Rαε≤∧h∧ ]<]
<C"Ntp
p@1S@≠≤X ∧ <h⊂⊂[<P⊂ /d∧AiQ∃`∂∃β≤¬F␈'4∧εF*
H ,≡Y<h∞]\|⊂∩Xts4`%d ded¬CkYβ#@~πMtαπ~→#!8εal@UJA←L↓iQJAα≠?KK,ε7ε@{Y~-lh≤p⊗≠z⊂7`& Tp∪@∧¬⊗≡∞β∃_.uh97Xp¬ss. ∀~(~∃ -T∧fv@Xπp∀e8∧@A&C'M↓∧¬vv@≤∧P 7or`↔fAEKGα WO∃∧εFF*∧λ
L≡X∧w`5pεAS]Y←YmKα!↓βOd¬w'~ ≡&*α ≥F`@"HZ-m→<Z.L8[⊂∩H9v7`4pεD@Zαi↓β'*βS#↔Lε"απ,X n 8⎇~.l(≥P⊂[8¬es ca`≤@↓EJAI∃iKe[%]KH@↓Er4T∧f}fMx
m≥Yh⊂~~2P4`.heri@QC]GJAaC@&C@≠Z ≥f"α ,V≡∂↑8 $∞α42Pλ30 `%MhAae=iP∨Sβ_ Tλ≥~ ↑y#"NL<z|d∞βtv , f`∪]⊂ASfAQsaSGα 2Sπα8
j∞Xπq`%pπf@:βQP@!αE⊗@--(
Z~(~∃β]e)CgWA` ><X nF@
IpπB`(HI"πo_6f∂>9v )xZP∩Xz9TFBα Su@AKeπYα @∨≠!∃∧∞w_X
.4yuwT90∂c@∃`∂M⊃Q M∨\(6f∂>7 JBα#"A_>_;.
α2y]αT ∂SS-P C@≤¬2mπ-xλl↑|j#!∧j0→@ASGCY∃qC@7∧¬F+Pα5≡.
8x;
L<zt∞4πce@M` 4λJq0∩pβ"C!*8 `!αK∂πJL↔=t≤[l<αyyFBα T`3ββ'∂πd+cπ↑λ Yβs⊂~ AfyTask@!β∪?∂↔≤ε0hPα5≠i≥X∧r4Xv4p~@∀pλ%↓αα∪↔≠∂+3@%L≡6@98π4`4ia`→SβS↔HQ!∃&@ty0⊗→qz'2↑8∧Su@λp ↓↓∧#↔6≤¬0⊗≥):v %S` @3,∧7&@|B#!∧j7l→xiz`"8∧∩@@↓ KMCUY`∩KαX Z≤[p⊃Yyyw`2
∪)=!P∨O$k?KS,¬S@!(λλλL9X=-Nα*0yZβPo`'β"7?KαLVn␈!Q JReaP@%++ ⊗KF@
Thes@∀@EMkαs∂S'|¬g4Kλ⊃ \β0p∃@1i)C@≤¬4Nvα8
4Xv4p~@∃` 1α&+⊂⊗∂]H
.αp eSelec@Q←dXAα+S
eDαε∂,QP@.α42`-pπ@↔L¬P∩\β units _Aβ;#'∂@πS#∃∧εW<αy⊂ #an e@aC[@'v)βπl@λ
]y~0∪≡T∧ i@_AIKgαK@⊗.EaP@!αE*4→P⊃& )pπa
\α⊃β >dλ
<h∪j:hεb0\βkProc` ggα{@∩ε≤∧h
mβ{P &ille@⊂AS@9bβ eβ≤¬vv@Y8p~~w3P 4he~∃α≠?&Tλ ∞ <y0↔≥⊂⊂λo@HA`≠≤∧]∞\8ε6 9 pre@MK]hR↓S\Ai!JAmCIS←kf↓H @.βXp~~ww0vλ9v7`4pεA←L↓iQJ~)_∞NMm#πO.αλ M|y<p→[y⊂:`.it _Aβ#=β∂|ε',<|⊂↔[2⊂:7H842P≤βche@5BAgQ=o\ASαqβπ ⎇3∃ 0β"C!!:z pπ↑AM¬`XA]<AW]J@Q←@⊂∧π,=~→.¬λ≠[d∞α0p∪@,R@AW9←ofAα ?↑@λ∞M~8 P≠4qrPλ0yy`%mb`→Kα 4+∂dεVoα
x D {y→%@⊂⊂"7H84rP~z⊂4`., each tapπVAo!SGPAβ;π;S~βS :∞X lT~8
mustAa←SαsP (αY≠d∞~~0→H'iaVU0yuh≤αh∂GKβ≠G?Ip∧αα¬<X
∞M8π3@ the Value h∂LAQCgVFLhu)←A` ><X ndrP⊂≥4π
OSS ≠& @≡]∞-v≡<|p↔\α acHi` mKβ→↓βSG→β↔≠4∧V∨"d∧α∧NβH⊂∪_qz⊗⊂λ0yP 4he Value o` @Aβ##'LhRS =∞-v≡<|s,Tλλλ∞≥≠y⊂λ⊂⊂4`3 @%]QKe%iCEYα)1↓↓αβO/L¬~-lhλλ∧∞~→(∧∧λ≥P⊂[8¬e of
λTq`!αK∂πIz5≥_8 eN*7h 2oces@M≠@∃↓∧εFzα∞MεO~∧ u≥~β5_.uh97Xp¬ss@=` ↓βn+π;Mαβ↔[↔↔KS#'v84+←FK∂!βLs∂3W&+@~¬M_
≤x;∪j:u_<m∀_<h ∀≤≤[nMβz4h→P;tv≠⊂:y`% OSS-TaskPrh∂GKβ≠O?Iε∪d4 &+∪πWdεBαjT
VvF↑8 d∞~→(∞↑y<@⊗λ8πanting a dif@→KeK]PAaCgαYβCK|≠↔OO|ε"π&tλ&*α∞Z6. Q( M}H≥~
≡h≤⊂..~8⎇-L<H∃ ≡zkλ ←≤≠~,==≠≡$∞⎇≠tL\λ≥~ T≠X;,T≠yH∞M_=⊂≤97qr\βsor on
this slot.
~∃
eKCi%]NAi!JA∨'L[βOK9IC!e=GCgg=`ASfAckSβ#∃βOLk'3π⊂¬BεF↑,Rε/∞ F}OM≥f*α l⊗∨'1Q'∨&pεAG←αsSK⎇Dε∞f⎇x M≡~≠<d∧≥~_.A ¬24→P:y`%p∧AS]Akh@9ααW/,Tαπ&
_ d∞α9:`%, RLL wou@1H@AQ¬mJAg¬GeCMαK∂.Dλλ-o(~≠n (λ⊂∪≠y
@MaKKHαβπ;⊃αCS'\URN∞lh
,=9;Xo∀→[p→λ842P≤βa`↔J↓←@→β4¬F/F≤-⊗fOO∃bα¬M ↔"ε≤∧h @'j⊂⊂≥42FE_pyrWλ⊂)&&λ892`3erve@L@AE←β#!β#L∧vBα
H .l8ε⊂ $escripp S←αs@~∧→hBαπ⎇ ↔"πM W<αP⊂ &or`≠f4⊂ ∂|¬WεNβ→(D
8π:7H⊂⊂
-↓C]H@↓Sh@AαK@~πM ↔"α
Hλ.Nα2y bh∂I@J↓β >d∧ε ,<⎇⊂_wr2Pλ8πhi@
P@ASβ_4+π≤εG.∞β≠⊂≤H9:w. @≠kα≠!β?2αJ2D}2ε⊗β{p~ yz0∩apping code is @⊃Km@?&+⊃βSzβ7π≥nF∞NβZ0↔→β
∃@&C↔O∃∧∧6␈↔,X n
βw22[1ryVλ9wP 4hat @¬]rAGαCπ;∨*↓β@&tλλ$
~9z∧
α2{ %l fo@IZA[CIP∂M↓∧εFF(β"J @4πrmep¬Y`%h¬⊗≡␈,∧Y.x7w2~w3P %xecu@QCE@3*β∂?∪*βπMβL¬g6∞β~0∩ α O@8AIK[¬]H@QQQCh@↓Sf@0hSS#∃∧¬f/GDλ
≥9(⊂~~0z⊂ #o` J@↓SfA]∃K@∪↔ ¬BJ¬)IBπz;⊂⊗λ⊂2|8_w2⊂ 4hat @9KnAQ%H∂!↓∧¬F/6]AP@,→9P∀[4z4`/n into r`+αs;π d∧Rαε=x Wh_;LD≤⎇≠n2P⊂ 4hese lh∂nAαc↔[↔b↓β≠|∧[.P9wPλ8∧he@d~∃oSαc1βπ≤∧6/∨<X ∧∞|→0∩Y4p `2↓]KqhαβS'\Tπ&FTλλm|α2P )pεA]Kα+∪↔⊃ph ⊂@"TS DβyP #o` J@↓GC@9∧∧&*α ≡&⊗OL∧X.4p `2↓H πO ¬bααλ∧X.M→<@≡M_;@⊂λ⊃0 nterpret" the hidπP~∃αc↔[↔bβ∪↔O≤ε&OπM_ mnhε⊂)∪&⊂3 )p¬gh@ G←[aαK3↔M⊂∧απ~→0→YP4w:≠P2s &icie@9hAM←β∪7MDππ;⊂hS@↔.β\h∞M~8 P→αastep∧AG←α#∃ 2∧
FFO4λλm}⎇_ P≠w0 `2↓BAG←αs@∨&≥nBε@⎇Y0→~2pr -(
AMα{@∩πM Rε@{Y#!8∧ime chardπ@∃β|∧bε/∞λλ-l~;Yd∞α40zλ8∧erse depπGeSββS'⎇` D∧⊃\[mT≥~→.2P7`. p QJAG←I∀~∃GC8AEJAα @⊗⊗α8
9_y0 l@dAKMMαK∂'↔w!0∩αλ¬~ T→Z0→≤βt tim`
ABαα≡⊗Q∧¬↔4→≠p↔→T∧ o@HA`∪#*↓β≠≤∧\nAα@
`)%[@∃β&C∃β[∞cW*
x D (~~,@t⊂6 %ve`_Aβ≠3 ?Dλ
.P1pv≠2r⊂ &or after @%ifAI∃H 'm_
≥{H⊂∀_yFE "e` @9∧εw-=_
2[⊂7p∩↓GQC]≥K@⊃Dλ
<Y(∞⎇8ε6⊂_2P0@ paus@∀p
β αX
∧∞α42P≠2|: (a`≥Hα↓β≠W'+@⊗*⊃Q'&Nβ90→H8∧he@IJAoSαc1β *β; :
mw&N<≤&f*∞8
}y≠p≠[⊂1w`-pare@⊂A`∨'&Aβ#πv!7∂K∞3S↔⊃αα3'Oh ⊗≡|LR`! ¬εE⊂αasi@
CYY@JαJ2D∧εF∂4∧πε∞α9⊂→αh∂d@↓Sif@↓H &←
⊗⊗Nβ~0~≡P4w p Ke5`
↓β|∧bπ∨ ≤6*α¬P $∧≥≠c!4¬ai@9iC@'p∧π&FTλ
≤β32`2ent ver`'αK?;M∧¬v $λ≥~ T_{p∩→P⊂
-AC@; ∧εv@⎇λλ
≥H≥~-\αW⊂⊂λ&p∂`%∀~∃IKβ#π'L∧h
⎇H~≠nt≥~→.p¬ mulp SAαc∃β[,ε'=8πw9H0y2P≠pp ntai`≥Kα!1βW≤∧V"ε≥lBε≡≤8
\α⊂1`!nλ
+⊗)β≠}X LD~;@⊂⊗βH K]¬hAKhαβπ2u∧∧⊗v"λεqn2pw2\αX
\~(~∀BdαqQ9EpεB¬∨α8 `4em F@¬GS@3LεFN<c"AQTp
)⊃dεGTHS
∀~))QS@~β@≡8⎇~-⎇Kλ⊂→[P⊂3 !p∧XAQ¬`
↓β,¬WεF≤8
/,9λ∀II x P≤βtre@9H∂S#~↓β@>
_λm∧→→0→~{2P⊂→αr`∨Z4⊂ 'Q?→↓ ∂|¬Wε/LX L<αP⊂ -o` KXλ@A←LAae←α;@⊗∞β;:-lhλ⊂∀[⊂3r`.eral, and of p QJAIC@&λ4+O'∪W∂SαX L↑h_;LD_;⊂∪[y0 thms i@PA`↔O,ε2εNβHλ∞ <X
4Xzp ar,∧@A≠¬]rA←α1β'Sα4ε␈& X D∧≥z0↔≤β
∃CIJAI@,∧Rπ≠h⊂∀]9P⊂ %np
@'⊗{; .]nB`$λ⊂Y,<=<p∩H4z⊂⊂~yP4`3 bui@1hA←\α↓β@&|∧ε}H⊂sj)⊂ε⊗⊂λ0@
@⊃K[C]⊂AaCO%]N@Aβ≠gOS,¬R¬\9z$deUDα¬∀IDαεO4λλ,-α2P⊂≥4π i@≥]P∨K*↓α'nLW)~8 `0's 252K
pπi←@⊗ ⊂≡(≠8/
8εzfK⊂0w2λ9z7`2e an↓CY[←β≠QβWvc'7≡LV"εnYV⊗/$λ l@⊂:w4]9S⊂⊂∪z42`2 b`∪N4⊂ π∪αhλ-nα0sr\β co@5JAMe=Z@A∪αsS↔Jd¬↔>λ~0~≤β` @32↓5 *∧λ
-l{_
`$ing @QQS@;?→β#'↑)↓βO∧∧Vf@~;YaQX{p→≤αection and inline @∃ISi←I`
0β"C!$0p⊗@%]NAC1XAW]=oYKI≥JAeKββC↔O,¬g&.Dλ
-m9[tM]≤∧P⊂≤βhoe@1HAEJ↓BAa←β;↔K≠,¬Bε⊗⎇z7"α∞MphV≡NF.o∞N2ε∂Dλ ,↑_+8m|{Z0~~{2P)↑yz2`-pεP→↓ααJ2Dλ L\9≤h∞M~8h
\αz0@-leve@0@AeKα G?;L¬f 1 X8M≥~=≡%D≤z0↔_p¬ i@PAP↔W≤εBεNβ{Z.Mβy⊂ !nd mode`_Aα ;⊃βn{∪'≠Jβ'SO,¬F %Hλλλnαy0∀her`≠←β∪∃ 4T¬↔"ε≤∧h∞
βyy`)bh JAβ#=β←⊗KS∃βv+]βOd¬w'~∧λ
-d≥→0→≠yP7`& h∂YHαβ?;↔~aβO3|εG4≥z~,=λλ∀m≤α{FE≥42P 3yste@4A`∪=∧∧&*ε]x LTλ_<∞∞Xπp⊂@ISCiJ↓iP≥α≤
%βSF 9↓β&yβC↔⊗3?K\≥f≡(≠p↔λ0P⊂ 4ask.
λ¬)QSβ→β .≥∀ε∞NDλ
-d≤Y0⊂[4⎇4`.dεA[kαcS'Cd∧Rπ<y0→H397`- a s@%]OYJ↓P∂;|¬{ \α3rP_0yrWβE
λWEAKL¬⊗Nα8U_hαC"J)⊂ε∪yH⊂14`'e` ghα↓βCK|∧&f.β+λ∧ =λλ∞M~8 Pλ9z0sYP⊂7`& i`)L@AIKβ3↔3?αλ ,]] λ∧
<hλ∧
=_ FBαi`≠[¬i`↔KLεGJ@Hλ⊂O∀→→0→Zpπn, it wilhλ@Aα≠?;SL¬g.␈↑8 ∂∀~;Xm}\≠p→_z2P .ew f@¬Gif@↓CE@?αX
↓QX{p↔≥93v⊂≤z92`#tp eKβ→1↓β4¬w-αyP /d∧@Ae∃aeKgα+;@&≤¬~-⎇Hλ⊂⊂[2⊂6wY2yP⊂≠pε @%]QKe%iC@;≤∧R`!α@
How` mKβ⊃1α≡≥→β@>≤∧h .αp l@PA`∨πβ∀π&@{h⊂∩Xy0 `2↓S\Ai!SfA←αs⊂≡}≥lrε&↑8
,@w⊂8 2oces@LX ↓↓∧3?HQ( / 8εx ,e(λA∀b1β#∞!β 6↑h .⊂2w1[zs:2\αed @∧A'←Yβ3π LT¬π⊗βx[ ](_Y,@4πre -(
AC1XA←L↓Sif~)aeKmαK?WM∧εv␈⊗αh⊂∀_p∧ been directed towards AM-like @MKCeGαC↔M↓h¬Rαε←∞εf←,≡FN}n1P@.βt4`#h ne@YKdAi∃aP↔≥l↔&*∞⎇↔&B∧λλ$ X∧w0[⊂0w9]p¬r (i`
@AI→_AW9KnAC ←khAβ#πO/~↓β#'↑(4)
4¬⊗v" X∞ ≥<≠⊂∩\β of pramepεDXAα∪WQβv{Q↓β∞∪?WQ∧εFFNβY|d
α4urH⊃+t0]⊂4qP≥42P⊂≤βource
∃←α1βS#*β@∨ε≥H ∧∀WεEβE w7]42y big @]KC@/v+@∨~βλ⊂≠Z4qt also pπiK[5K@⊃β4ε&}j
_
∞P8 o@UiP@1∧εv∂~
_
∞P60qZβ of a
∃Kβ≠↔Iβ4ε&}wDλ -l Hλ∧λ(≥≤M≡X∧pvλ⊂2|0[x62P~w;7`,ves @QQJ@Aβ;πeβ>)↓β←,ε&*εmx L<9λλ∞MβFE %np KdαβS#∃∧∧6}→( %Tλ→0≠→y<r4~w3P 7as i@8AB@A1∪'!rQ∨↔%3π3W*↓≡ .≡LW-8;λ∧∧pπ0vYTVεE≤αathep than a @9SGKdα↓∀n≤LW-8; nP70vYQ↔⊂⊂⊂z⊂0@ deep@∃` β3-3↔1D
$db M⊗"εmx
∧∂9=β!40s % a`≥r↓]P∨SL¬vrε|dε≡}nLWGλ ⊗H844`3 f`∨e
K@Akβ→β∪↔≤¬⊗ =Y<\d∞≠h⊃/∞≠~0⊃Zz6<Pλ88 `!α(4)#≤¬vw&≥nVNvt∧π&FT∧αε∞-zf*α X∞ ≥<≠⊂∩JP⊂⊂⊃∪pz2`2ia`_@↓]C@7*⊃↓↓β⊗ S#↔⊂∧απε ≥bαα∞Mε(hαJ≤n\YZ0⊃Zp¬`≥hαI↓ l≥V*∩d∧∧
ε⎇x lD→\[mnα⊂2`.d c@=kYHAαCπ[∃∧∧⊗N→9⊂~w⊂:4→P22`3icn o` 4TεFFO4
7O∨LX %D_Z(∞zssr\z4w3H0x8 2opriAte Data @MiekGβ#WK↔~βπ;⊃∧ 3∨?⊗KS#7~↓βπLhS←*∞|Vw Hλ
M~8h∞MβwP 7as mipπgS]≤Xλ$!Q$
π=\⊗f@→<@⊂≤βhortcomi@9H
" ≤v∞NβH⊂∩\42vr\αa`_X↓SfA¬1_GfA⊃KaK]⊃K]Gr↓←\@A%]`∪↔∀c'OAph*?W⊂∧εf↑lpλ∞L<[ ∞
α0w9H0y2P≥4π build RLL inth∞AB↓[←Ikαc∃β←FK∂!β≤ 9β *βCG→∧K9α6∃_4*@9Z%≥jd∧¬∀dD∧π>NMEBε∂D∧π&F≡@λ∞
z;]¬Dλ~;M <Z5∧∞~→(∧
88z
≥Y(⊂-lλλ∪ ~t 9
≤9→0nAα@
iNdepe@9IK@;≤∧Rε↑d U∃~aQ hU)IB?~ h
-l9λ∪,≥Xπqλ30zv≥⊂9rb[yP⊂0[4p∂s@PAaCe¬IW`#L≠π1iαβ'Q↓∧εv∂~
~B?~∧ ⊗nn]n6(h,≤F∂πL≤&Nf≡O∩bα
Mvzε↑\6Bεn,V.&⎇QBπy(⊂∪≠zs2, f`∨e
KHAkLAi↑Aβ≠C↔l@λ ={\p∀Y2y0q≠2@
@QS[JA⊃KGSI%]NAo!SGPA=H β7∞seβCf WO'⊗c∃↓β⎇βS'?w→βK↔∞c3eβ> @~πM Rε⊗↑8
¬@⊂⊂⊂*~4yFE≥4rrVλ5s⊂ #ours@∀XAoCLAU←@ β'31o≠C↔≠!YβS#*β∪'≠∞aα>N~β'Mβ≤∧Wπ_:3MO(_Y.Nα2y≥40wεB842P≤93r:Xz⊂7cλ0s<P≤|yz2[P;t4Xt⊂3'\αced↓BAGQ=SGJA¬hAKC
PAgi∃`XA[=YIS]≤@A←kH~∃MS9CXAG=IJAi<ASCi
PAiQ∀A '¬@OfAY%[SiK⊂AgKhαβ?2∞Z6∞⊗LTε≡}↑ vv.nN2bα
w>∂lX EA ¬0yH9zqtλ2|:2\4εal consTaifts wou@1HAGKβ∪Sππvceβ#∂3∃β;∂∪K ?|\Bε&}⎇bε←↑ λ∞ppy1Z⊗εE+YP6tcZ:⊂2k→w⊂40]2P3 )nished the sycTem i@8AiQJ↓IP∨W⊂∧ε&∂≡4π>
∞|W⊗*∧ ⊗ff}NF."βC"J\αP12[4r{ % thiq ty@AJ@A←_Aae← YKJ@↓G←kY⊂AQCmα)↓β .+9βπfc↔['∂#↔⊃↓∧K9β¬αβ7?K(h+ .≡NW⊗*∞;↔∨&]P ∧∧≥z~,=λ~3L=≥9→,Dλ_(∧ {{< ↑→;]∧ \[{NDλ→;LD≥z~,=λλ⊂≠[zv2λ40{ %
se@ImKHA¬`
↓ >+;S3*β∨W'&)∩εNX M≥Yh∃
<h_N]8ε24[3P8 2ocesS. α
!2.$.1*5 Concluqi`∨\4⊂∩*>)β←'daβ∂?v≠3@.LTπ>NβHλ ∀≤→4Nx2q`4ive Od∧@A¬1_@ZZ↓S\Ai∃eP↔Mαβ?→βM#@~π ≡7"b∧ ↔'_Q(7/↔,Yg"π>L↔'∂5Dε∞vD w/∩
H mlh≥→.-αP8 ,ans.
αTwo qeAps ago, BLL beGan as a @Qo↑Ao∃KVAaβ∪?+↔≤εBπ&tλλN]8ε2_P⊂92\92y`%np CI%←\
∃αcπ;∨, ∨¬β|¬bπ>
_λm∧λ≥~ T⊃54I~rsh∞∨<⎇→-Tλ≥{n]→λ⊂⊃→P12`)lp ≤@A/JAM←←\@↓eKCYαKk↔⊂hS7π;Jβ;?9o#C'[L∧⊗bα∞,W≡8<Xm∧λ~<n>9<h∧
_9∧∞≠h⊂⊃→P⊂0r→92y`3ed Befgre su@
P@AB4∃OK]∃aC@1b↓βO↔d∧bn.βXp↔Y4p∞gλ@AYC9KkCO∀AG←@,c⊃↓β⊗)β∂?w≠SKW≤εF.αβHλ∧
y(λ ↑Y;]∞\;≠⊗!QX8X-l≠{Y,D≥~→$∞=90→]⊂37`2 thi@LAcI@&K7πS*β3πl}V∞≡UDπ∞∂M~6'Nα;Yd
⎇<\l]≥Y4d∧≥z5
↓ X
4→P3rg→y0v$] "experti@MJACE=khAKβCC↔KαM↔<+H@⊂λ$z⊂⊂~yP:4~yP5w≠{v2`$dπJAo!SGP@↓K]CE1Kf~∃I→_Ai<AMC@≤¬εN}dλ L↑h⊃4nP;t`4h g`%∃CiKdαβ↔6m_λm≤αp∞c@dAC@; ππ∂∂,ε&∞∨α+@∀
~→(∧λαj`∩ISK@≡~)`∂gO&+5 " /∩∧f]l↔"b∧λλm⎇]_:-nh~{M}{→0∩→β`
AE¬`∂/4∧ε∞⊗βx
zλ2p e@5K]iCIr@A[¬iQK[QSGfX4⊂ ∨πn+@~@λ~→.↑X∧p∪@QSGfXAeKaβ∪↔O↔w#πS'|¬bbε≥lBα∧β~0→\⊂897Yβramming. Thep¬JAo¬`
↓βvx4+↔G#@⊗
∞⎇w-h≠Y,\α2r=4π add "heur`∪gβ#'∂M⊂∧απ≠h⊂~~0z⊂ ,ist, pπS@;≤∧Rε.≤8
∧∧~→0~\αistic
∃@> @~ε≥H L\9_ P≤αeprepπK@;&+⊃βSF)βOπn)β@>≤ε( ≡hε⊂ %,¬N@9bβ↔π∂@π7πSF+7πSL∧6∞b h
-l⎇~0↔[↔
Thp fAβ##∃βF+WK≡8
≤|h⊂≠Yy2P⊂_v92`!dy c@¬aCEYα)β >dλ
m}X¬t`.dε@A←αqβ↔π≤¬αε@⎇~→.↔⊂⊂⊂⊃4πr
instance, a he@U` 'O&K
βKαX T≥~_.D≤x:,DλR0∪λ0p∞ @=aKeCQS←\AαK@~π=x ,↑~;9.P⊂:`3e`
kX4⊂ W ∧ααπlX O∀λλ⊂~~vrq`/nsuming _@A)QKαq↓↓β≤εε.≡≤≥FOVT∧αεOD λ∧∧_{p~[2⊂⊂⊂_x86 9 to
Fu@9GiS←αsπ2∂|¬Wε@|z0~~ww⊗⊂_8¬t @¬Yg↑Aβ#=↓βF+WK≤∧p~~qyP⊗KP4w d¬CGhαa↓β'p∧ε}vTλ N]Hλ⊂↔Yαλ
*,εW-<z{eD~8
even app@1S@↔⊃∧εFzα
_
∞p¬`→L8@A3Lε7απ∞-v >X;;-≥Yhλ ≥≤{h∞2xp∃@%` ↔⊃αβ;,4Tε&.∞βλ⊂⊃Z0p∞ge in↓iQJ@↓%→1αβ@∨O>LVj@λ_<d∧→88m∧⊂ε4`3p fUncti@=\@AQ¬`
β¬αβW;≤@λ∧∞≠c"N <≤Y.p¬ft↓Sh@9ααP≡F≥H $∞Y8<m⎇X;Yd 8[p~]⊂"4`3p predicates _A∃ke@'α8
mt≠[p~~qrr tha`(4⊂
-∀λλ.∞→8<L\α⊂:7H12P ! re@Mie@'≤εFN}dλ l@⊂"`⊃UAH _Aα#'O+|¬⊗v.D∧ε∞rλZ∩π→<p~λ5w:7H⊂:42CE397[8∧ o@_Aβ#+¬_X@Aβ#=βO,∧RεNd∧π,9H⊂∪_yz2`2, and lo and @ KQ←Yα!↓β'α@ε&ND⊂λ∧∧∃~~.FA6t[5y⊂#[4z1dλ⊂4w Inte@IYSga⊂@AQCLAgS]
J@AE∃K\Ae∃aCC@⊗+⊃9↓αα'9β&C∃↓β4¬⊗.fD∧ε}⊂β"Ql≥9<k∧λαzy4\uwP !ppli@∃H@Ai!JAgC5J@Ag∃hA←L↓QKke%ciSGL@ACf↓kgKHα↓β'→∧¬↔"α
x
<C"LM{8:-nh≥≠d∞~→(∧∞α0p∪@,AP∨→∧∧F/≡≤⎇fNvt∧ε
εl≡f∞b h \=λλ
|H≤r
≡≤h∃
tλ_Y$∞αyr`$ in
λsargames, a`≥Hα↓βS#*β≠ &\X
∧∧~9λ∧ →<z,]Y9⊂≥ww⊂⊂→4y9`4 placa iN the national
Travellep∧A)πLAM@3,+Qβ ∂#S &T∧π&@⎇<[L≥9;]∧
{H∩N]≤∧P⊂ VZV⊂ \X⊂⊃∞ The important
∃S⊃KBASαqβπ∪bβS#'~β'Mβ&CπQβ≤∧Vf2\LW∞∨.-↔π&≥ybε∞l@λ∞]X9Sn4¬ady are pkweRd¬k@1α↓5$∀Tε6zπ
x
l↑Y]0⊗λ⊂:40]⊂:42↑P⊂6w\2P⊂ 4haf @IKaCRAiQJAS@;LεFN∞βλ⊂⊃[yz⊂⊂≠pε Carefullp∩~)IKgGβ∪' πv9β↔[,ε'Jπ
_V≡
x D∧≥~→$∞|8 `4em to itself.A⊃C@4¬⊗v:
=f␈>LXF>(λ⊂≠Z4qtεB1pw_2P⊂*\pr⊂⊂_qy7i\β doMaifs h CW∃b@AEUSYIS9H
β↔Gβ↔KQαβ@∨O>LVo~∧λ ,≡z90→λ⊂0w2βE2pyZp¬r, as that c@=[[O\αα. β?∪?←Mph (*⎇εNfT w&F↑ λλZp\λ∧∞|8p~→vyP$_{2P⊂≤93s %n expedient fOp∧AiC
WYS]≤@AaCIiSGkαcπHQ( ∞
βq6 %ms iN particulAp doMai`≥f0AgkG @AgsMiK@7~βO.]PεNv↑8λl≡_8[∂∀≠~;-≡→9⊂λ4p∞
the Scope o` Aaβ∪? ∪.k@~πM WJε<≥bαπ=yG6*d∧¬>(→P∩Yv⊂:4~yP8 2obde@4ASf@↓S]ie%]gSF4⊃`∪=∧ε7.≡∧λU≤↔∞5Bε∂D∧εf.≡8
∧∞8π:4[⊂:42↑T∧ l@%P∂*∧λ
(~≥-\;H∀∞-βsq0[vry9H842`9 are
t`%eS]NAβ#=β↔o+3πS*aβπK*β∂πC∞∪3∃β|∧bαε∀λλn8¬de unde@I`∂Sπv#';≥∧{⊂∩πM Rε≡|LRαπM WHhαX<LT_8
:→vx:4[3P:7H:7P #ompo@MJ@@5h∧ε∞r∞Yf&/,8
≥Y~0↔→β which i@LAMC@⊂π∪↔↔∧∧W$λ≥~ ≥@εE 4he s@UaKeMαK∂'πbβ3↔[,¬Bε∞β↑( ><X 2[8∧ s@eciKZα↓#'l8 ∞\α4w3H)&&∀H40qP≡p¬t @¬GQSKβ3↔"βC"JM~8 P≥wy5@ dπeKnαβ?WQ∧¬v $→8<MM9<@⊂≤αese@¬` ∂!∧¬vrε≤X
⎇89~,4≤≤[l@y0vvZw3P-Qy2r`. et
λ¬C@1b↓↓E@⊗rUj@λλλ ≥Yλλλ~λλλ∞z4v , se@YKf@@↓Cf@Aβ##∃↓α↓⊗.βYz-l(Hλ∞M_9⊂λ⊂1w`.verds
se@1H 7∪,ε6∨⊗α8λ 4ion @%]`∪=∧ε6.fe]V}~9P∀Xpz4`/n. RLL wapεAoE%i`∪↔p∧π>OMλ∞M→(⊂∪[pp @=Hλ (αX=∞L8∧w4[3P:4→P72`#essary l@∃mK@1∧εVv&↑.F∞vM_ L@P⊂:7H1pp∩ry o`+P@Agkα≠!β¬αβ7πO≤¬↔6(β"P⊂]z7vp]4qP 0p¬P∨∨α,⊗nnα;Yd∞α0p∪@,Xλ$!Q"λL)_$dLxz$
∧α⊂ FBαλ
*\;K↔↔p∧ε/" ≥Bβ;Xπ ⊂∀90∂gress Repo`%PAW\AA` >|∧X-T∃;Y ↑\⎇_-l~;Yd
|∧p∪@QK[fX↓'β∪_↓≠C@7xh ∃\|,VNv↑ ∞ε αP⊗@ ¬%→_4bt@\8X λQ+4?⊗]_ L↑H H L8π0z∞_0n@ - AAAI
∃7≥aKC]∃` ↓→∧c↔;παCβε∃β( $λα2z0Zv9P /d∧A%→0~∃ .d∧Vv∂Dπβ
jλ¬~ T⊂π0z≥y2P /d∧A#,εW-<⎇~,>hε⊂$∀(⊂&r[wP0w→⊂,2`2ox Bepkr`(4⊂
n∪,¬f∂"βλ∩ ∨9<k*-βz4, A> S↔Kn :`*¬Pλλwsw4]4{2P⊃qww7[|@
[Smadh] CORLL
[G` MKβ≠↔K↔&A1α∨⊗+';↔⊂∧α2¬=]↔&ET¬R∧m*1P@@ @↓A4S∪∧∞⎇8Pm <≥→.∧~;@⊂⊂αAS @ ←←V~(≡bh[=GhJPβ ↓↓AK→H',≤6@=9(⊂.D∀P3HE53R+∧α(λ∧∧∀S∪∧ z_<∞L<C"JMnH∀HHβP0zλ)jV`RF@
Re@M`
hQ!PDF↑,RεO4λ
(≤⊂↔\αp S←αqβ >dλ∩ε&|8
-\αp∞t↓∩ACZαβ←KπαM⊗v:∞Mε∂" LV∞g4λ
m≡~λ⊂≤[zyεE≠0p∞gua`∂J\α↓αS#M→βO'd¬Bε⊗\8 m\αP8 \8∧ o@_AaQJ↓H 'l≥Bπ⊗↑λ n8∧ o@8AaQJ↓KqaKβ∪P (αX `9stem↓o←eWMQP∨Ap∧α∧ODλ
.P0P 3um`≠CIrA←L↓iQJAβ∪↔C?↔!βg∨αTεn∞LTε∞⊗βy0~λ:42FB8πorkpπQ←@↓KqaKβ∪'.βXp∩Kα ∀~)!P∪↔∂≠∃βK, ⊃βSFK@~ε<≡&.];⊂⊗≡P0w2λ1wq9→qz⊂ !ny e@I` ?.4ε␈∩
]↔<{{Xl↑≥~0↔[9FE'[⊂6|P≤0y0∀8@A)Q∀A←]YdAG←]MieCS9hASF↓iQCHαβS#∃∧εF/GDλ ]Y⎇~∧
αzy`4 h
@? h#'l8 L\<y+D∧∃~→$∞Y<⊂↔\αpλAO=KfAi<AakE1SGCi%←\A←αqα?∂&{ ↔Iβ⊃I1β≤¬rπεLXλ.<αBE 2espo@9HAEr↓≠Gi← Kd@@⊂εαε∂Dλ
(≠⊂⊂]2yz
_P;rYuP3 2om now).
Thanks @→←dAsα{WIβF+3A⊂hP4*∪|p4(Q!P@J∧∧ααα∧∧2
~4424hhhdQQQQHQQQQHβ####!####!##
∂TO @@∨≥↓%C@; ¬U.vα>⊗λ% aeRb`!0[2⊗j`.ix$ CSD.LENAT@SAH∂%
@bntDr@br5≠Gh~)%→_Aα≠#πC&+H (!Q$&@{H !Q@εE)[y90→ th∞AM=` ∂∃πK?UβL¬g&Z∞9rεN≤8 m≡Y(⊂$∞Y=|M≡→+@⊂λ$z⊂ !ppearq the docum` @; h"%β> @~π}-↔&NβY`⊂≥pyP [⊂7y2→y⊂7`& iagnitude ig`%∀AIKi¬SYKHαβS#πpβg?U∧εv∞wLXBrraQ hT∀λ ,≤→(⊂$ Y=`⊂_wy12Xz4wg≤β to the Documenp ≤~)≠CMr↓←@→β&C∃β∂|k7.β]≤d <Y( =_;Ym≥YhλM]y_;
≡~94d∧ + ⊂≥4π give the rePort
a hi@≥QKdAαK;@&↑.6.∨M_ md≥z0~~⊂92`!lity.
O`)!KefAα C∃β∧¬vNwLX NP:7P≤2s2`2ence@LXAoQ%GPAi!JAS]QKeKgβ#↔"∞,V∞→<@⊂_pp∞ @QQK@8hS∪ >MH nuβαEεBαAfy@]CrXAβ##∃βd¬⊗v/4λ ∞ 8y0∩Y2r⊂!≡P⊃∃∃
⊃⊂0y→P:42H4πriGinal;
`≠r↓GQC]≥KfACIJAMYα ⊂≡y9⊂_<P⊃>>8 D\4⊂
π∪&KS'⎇l⊗bε≥lf␈⊗β8=
≥{H⊂∀\β enclh∂gKα!β'd∧%@;vh\e@∧¬∀Q%
AIKαc↔S'v9β@& TεfNβY0→H12st[4ε`∪]≤A`∨'αMαα∩%%"$_;Y∧∧T¬`≠[ ∧AYKα [↔M∧π⊗␈*∞⎇↔&@Q( /∀_;⊂~→y92`$ rep@=` @#4λ ]→=~-lh≥~ TλO@∨∂⊃⊂0w→⊂⊃-mVβ" l@%]KfAαc↔π[,ε2π~→(∞ <→0→λ<p∂u pπK@; ¬bHhαC"JM_;ZnP37`2 y`∨j↓H∂'[L¬f 4≠9( ∀≠_<nD≥{p→→⊗εEεBαRus@L~∀4Ph ⊂J∧∧ααα∧∧24hhhdQQQQHβ#### εFFF @
~→~~4424hc"AQ@εEεBα @πβ'
↓' ∩V%I↓Y@$
$d`Q!P@$λλλ @{2y;~p¬w @=H αJd`4(Q!∩αα∧
$db
_ d (β"Ggβ_∞ struct`+β∪↔ Q$ααα 8 mMα2q`4ion @=H βS|¬vg~∞MrεF]H ∧∞α42P~βn`∨@>c↔&|Tε.v⎇_ L\αyεEλ⊂⊂⊂ #onstruct, use, and @5←@∪'4π∩ε/∞λ .8∧ s@e`∂S↔o→↓"∨α,VNv↑ ∞∞vD F.v≤¬⊗λ_X 8@X⊂∀$∧αα∧,≡'>≠x @, et @¬X\X@DrpdR8@A'pπ?;∃αβ@≡.β\p∩H⊂)&&λ⊂4p∪ it`'∃YL@Aα 9↓β,ππε/,¬≡|yz2[F@
*** -(
@Aα[; ?⎇H ,@pq6 %
>>8 @@@ZZ@hπ]@?α⎇F.→y0⊂X4∧e #E⊂⊂⊂λ4p∞ @→CGi@~βπ |¬=∧∞≤[p∪\αa`≠[%]NASαqβ∨↔v+@⊗∞β β!⊂⊂⊂≤≥Yλ⊂∀]9P7`7n su@ ` ?W&K;↔M∧¬⊗rπ ≡'&N>X ≡KH
&F≤∧h ={<⊂∩]2p∞c@dAaKe5SifAI→_@Aβ#<4$∧ααα,¬0↔→2y0∪tand" it`&AS@;&+@⊗v≥DαεNβYP∩\αe`≥Gα)βCK|∧6.≥<Y.T∧ and provide@LA`∪#(h ∩α∧∧π/≡↑ λ∞⎇=~⊂λ0P⊂ -ea`≥fAM@?⊂∧αε@8πr4Yαy`∪]≤@AiQ∃`∂∃↓∧επ-βsp∩ams @Q↑@A[∃Kh@AαC'L4R↓↓↓β≤εε.≡≤h
,<=~0↔[9P∞ The RLL s@e`∂S↔h∧ε≡}nL⊗Nw4λλ$ {{⊂⊗→qz4`/n of cons@Q` @.>N0hR∧∧απ<y0∪≥v⊂:7H8∧he hπ]@?α⎇F.→y(∧ 8π3t[2ry, inclp ISαs⊂~α M⊗ ,Y<Y-nα⊂⊂ 4ypes h∂L~(@@@Aβ≠3 ?L∧k∧∧_{p↔≥90∂l h KGαCπ;≡8 .T∧ @%]QKe%iC@;≤∧Rαπ<8
]9<k∧∧_;Y∧
αrz4≠p∧s @=H βπα8 m|z8=
≥Yc"E%JHλ∧∧≤≤[l<αr0∃@IKf@Aβ;'S!β` ↔LX
L≥]λ∞@=Xπp↔le` OJ8@@~∀x|p→↓α↓βπC∧ε&␈π-_λ.L(_8nM kf
the f@%]CH@↓csgi∃Z@@Z4@AeCQQKd@↓iQC\AMOe
J@Ai!J@AgegiKZAS]i<@Ag←5J~∧@@AaCIiSGk1Cd@A→←eKC1SgZ\@A)QU`
↓β&C∃↓β↑s?←3.#∨*∧λVv>≥lV/∩∧
ε∂~∧ w⊗.≡APRα∧∧εf∂M~G.→(∩-d→→= ↑[:0↔~w3P:~2P:<\2P7`& contrh∂XX↓CfAo∃YPACLAiQJ↓MWeZαβ?λ4R↓↓↓β&C∃β∪∂#¬(4Ph 4$∧αα¬∞-v⊗@→; λww9dY2y2rβE
The BLL team co@9G@↔;'∪πS↔ ∧ε}r∞Mε*ε|]f/⊗≥Dε∨⊗≤9↔4λ≠8-l9y;,]]β"D∧λλ∀∞-βq6 %m with Special emphasiS on determinang phe source loCatioN, ∀@@A)Q∃rAG←αs@≡NLX L\α⊂9jX897a≠2ryPλ90w3Zw3P⊂→αrgmASIK9iSMsαK;≥↓∧εFF*∧
7εNMAPBα∧∧εn∂LX M≤8ε⊂⊂≥4π Perfo@I[S@;8∧απ⊗]\V&N≤M⊗}r∧λ
≡z|k∧∞⎇8p∀λ0yP .otifYing The~∀@@ACUiQ←e%iSKf8@A)Q∀@Aae=EP∪↔h∧αε@yHλ L8;⊂∀[3P⊂ 7ith the ti`≠Kαc';↔≥→↓βπv 4)↓α↓β/K&+C'lpλ∧
βs⊂)]q:0yZβs wapεACYM↑AG←9`∂'∪-∪↔↓↓F);≥→bβK↔∂|ε&&Nlpλ∞M→(∪L≥9#"D∧λλ∪l@⊂0P 7itneSpεAi↑↓BAi←βC'
β∞≠'↓β≥β'31π≠#/Wd∧Bε⊗TλF.⊗↑.&."∞Yg&NAQ"RR$∧ααε TαεO1Q#s@MHλ∧∧_9U ↑H~→$
_<h ,9;C!∧λλλ∞|<[Y,D≠[p~λ:7P "reathe the fumeq).
~∀@@A ∃`∂'∨p∧ε}H≥~ T∀Y4n]≥~3L@P)|`3te`~~(~∀α@@A)Q∀A%→_↓iKCZαβ∪↔∂L#↔"∞Mε.O$λ -|α2v⊂≥wzv"λ860|H842P≤αh∂YJ↓←@→β&C∀4$∧ααπ>λ
-Mα⊂⊂ #p¬SgSβ→↓β7∞sπ>]\Vwλλ⊂∩↑82y: α Dhus @QQJ@Aαk?&]Dαε≡⎇x LM8π0z→yP0FB⊂⊂⊂⊂≠8¬`≠E∃` β?2βSπO←→1β'v≠3@.M_ L@P24`2ecti@9H
βSF)βπ∂&K['SL∧W4λ≠p∪λ⊂:42H⊂9x )lhλ~∀@@A← `∂/,¬P∩\αs _Aβ≠↔;∪Ls⊂~ε|¬0~λ4εew↓iKC[LXAC]⊂AU@?αM⊗ /8∧w3H0zz4≠y0p∀ies ≤~(~∀%α↓↓αSF)αJ2bβ7?∪,¬BεNβXp↔\αpobates @→CGiF↓` πl⎇⊗v: h M⎇(≥P∩\αy General
∀@@Agi¬iK@7,¬g'~ ≤&␈/Dλ n
9≠⊂→H87P 3peci@→SFAGα{; 6\8
≥{\h ,=→y,]H≠8-m≠{⊂∩\β in
λ the @⊃` π≥l⊗>(_X.tp∞.AβIGαyβ'l8 ∞\α2r are @IKaeKMK]iCQS←]fAP∨→αβ↔[↔w#@~@β"H∧∧λ≤p~Xt⊂⊂ \β "oil @MaSIYαK;≥βLsS : ⊂λ -βr4P≠pε water @
CkgKβ→β¬β≤¬ε.∞βKHDλXπz4βE⊂⊂⊂λ30qj≤β and eve@9ifACIJAeKAaKgKαsS↔⊃∧∧↔4∀S∪∧∧];Z.NiHC!≤ε0≤\α↓↓↓↓E∩21βLs#↔KLεF.λ≥~ ↑y(⊂⊃[w9z9≥qz9P→90∂m↓↔%_Aα ;⊃β&C∃αWvKSMβ∧∧⊗≡↑≤|R`$λ⊂p∩YF@
>x|@@@↓3¬@?↔∪?]↓2αP≡Nβ[p∪\αad]↓C]HAm'iKMαK ≥j h n⊂0r2~z4w`.al i@9H /Kn S'∨p¬bHhαC"A∀λλλλww:9≠v⊂7`& phe h @?&+1↓βM→↓β ∂≠↔"∧λ mdλ_;D∧_9y-l_(λ
\αqt0[4yvFBα contain`∪]≤@AC\α↓β ?,LWε.Dλ
≡⎇λ⊂↔Yα tashπfAi<AEJAββC ><X n≤αr⊂ 3eque@9iSCYαce 0β"H∧∧λ⊃0⊂Xt⊂:0\βk Ipε@AI∃`∂'∨v+⊃↓β&y↓βC,ε&&@|[ ⊂λ0P⊂ 0arti@
kYCdα↓β+∨⊂¬Bαπ>Xλm∧λ_<aQHλλ∧ →=→.4p ning @QQJ@Aβ≠C'∪b↓β'π&+@⊗N≥EBαε≥↑εf.β90↔≥4s3@ counter`≠Kα OWK,ε2ε←!Q"αα∧
πεNnM⊗v:
→g∨',XλnM9{\d∞≠h⊂~~2P:`3er. Tasks h Cr↓C@∪⊃∧¬f/:∞L↔=|h⊂~≠P⊂:4→P0sr[20VεB⊂⊂⊂⊂→U3W, the imple`≠KαsQβ∂|εVw→<[,\<⎇0→→yP:0\βk
*** mi@≥Q`⊃β∞#⊃βS∂≠ ∨~ h n⊂0r`4hkri@QrA]←β#'6α8p⊂]4sw or @MaSIXAG←]QCS@;n+;@"βHλ↓QLπ⊂≡x@@@Aα ∪∪M∧εF∂≡>4ε&@|H⊂⊂]z47`2itp∩Aαs?S'4¬⊗≡∂M_ md_;Y∧ Xπy spi@1X@AGα{;@&≥→fn8π:πλ⊂εE⊂λ⊂⊂ ∀apπV@Aα+c↔∂,εFN}aQ"αα∧λ
-nβ3v 6es @
←YYKα≠S'lpλ∧∞Y;⊂∩]0p∞t↓` @.β→4eD≠x 2→y0 ng phe@4XAC]⊂AM@'⊗K;≥β&C∀4$∧ααεM_ nD~;@⊂≤β` c@,∧Vv≡U`λ∧
~→(∞8¬`→Kβ→β .≤ε(∧ →=→.4¬`∪]∀@A]Kβ9↓β'v3?K\≡FN}eDαε∞LAP@$λλλ ≤α24`4ional r`+αc↔M↓∧εFzα∞Mε*α 8
.92w:λ⊂90∃@1KgKhαaβπ∪ ∧εv/tλ
≡z|h∞MβP:4→F@
>x|@@@↓GkeE∃]`⊂4R↓↓↓β∞;↔;∪λ∧ε␈∩∞8
.x2w2λ8∧he cur`%∃]`⊃β& @≡Z∞Mrε∂|≥↔"εlXλl↑|x<O∀≠Y0≠H20p∀a,∧⊂∀!Q Jα∧∧¬&FT
$db∞LV∞j ≡G&.β<⊂~→p∧ to h CW∀A`∪#*↓β .βy→-Dλ_<d∧→y0↔→y0v⊂λ0p∞d
λ∧@@@↓KqiKαs@≡N-H $ <h⊂_≠yyt`"le. Each↓aSKGα)β >dλ
mmβ{v %dge
*** adde`λAi<AaQJ↓[←IKα`4))RQ↓↓↓∧εv∂~ |Vv/,≥FOV\@λ
}H_8Nz90q]2r↔ As @∧AeKgβ+3@"βλ⊂⊗[yz⊂⊂≠pε @QQJ@Aαk?&]Dw1 ¬∃∃
⊂⊂⊂⊂~βn`∨o1K@∪∨*↓β'MαβWOπ⊗c∃β'p∧ε⊗@⎇~⊂≥42P /il s@ASYXAββ@⊗@x[⊂∩[P0w2βE_∞ <βq↓↓↓∧εv∂~ ≤F&.Dλ
t≥~→$↓α@
>x|@@@↓Caae=ae@'∂#∃βCd∧⊗≡(~0↔λ8∧he mode@0XAG←αs;↔∂&+⊃βSzβS#∃∧∧↔ππ-x ∞4pp∀e
0≤@sq↓↓↓∧∧v.v↑,⊗fO,≡FN}e`λ∧λ<h⊂⊂H92y`5lpλ@1∧εFFO4∧εn}LX ∧}h~{M}{→0∩→β`
AGα{W3⊃∧∧V∂≡≥H∞$ Y#"Ggβ_∞ extende@⊂AEKsα{;⊃β&C∃β?L¬Bπ∨
_
D≤≤[l-α2v@, p ↑AαCπ;∪d∧Rbεmx D >_;.
α2VεBα the @
←]mSα≠QβC⊗{ &]Pλ¬
α7q`!ti`≥Nαβπ9β,ε6≡∂ X ∧ {{]M≤⎇λ⊂⊃≡P:0∩aci`≥NβiQJ~(@@@Aβ∪?π∪α4εF*∧λλm}8ε2=90p⊗@∃XR\~(@@@AQQJ@Aβ#↔πT∧ε≡F|∧p∩H⊂:7P≤βacrid¬SGJ@ C↔⊗3?K]_ L@P0P &lashy demo ∧⊂∀$∧ααεmx D∧\Y0_≤αese@9iS@;8∧π&F≥lw4≥~→$∞X∧st≥⊂;p|Hα; but had p ↑Aβ≠π∂KL∧fN≡T∧ε⊗@⎇~β!⊂⊂⊂⊂≥4π @≥KhAKβ3↔9βλ∧εn89y.⊂22`-onstratio@8Aae←α;@⊗∞β(λ∞:p∞ning ≤@↓αAi@⊗ ;O∂⊗KC@ Q$ααα
x D∞α42P∀& @5←@∪↔bβ ↔≥lrε∂∞λ
≤αr⊂ 4o the spi@1X@Aaβ∪? LX $∧~8 Pλ3tp⊗@∃\@ASαp4)↓α↓απC∧∧Vv&≤ελUβ
λ∧⊂∀$∧αα∧↑hλ-Nαpr4[w⊂7`& RLL
λ∧⊂∀!∀αααλ∧S DβyP⊂≤βtre@9KiQfAIKe%mJ@Aββ@⊗Nβ8<M≥≤∧P⊂→αr`∨Zα↓β'S~↓↓ ∂|kC↔S,¬f≡ εE⊂λ⊂⊂6wY2p "@A←L@Aae=H∂Kπnk';≥αβπ;⊃αβ?2∧λ
.Nhλ⊂↔]w⊂⊂ $ata qtr`+α≠S@/,X d∧_;Y↓QHλλ∧ 8ε3w\αithmpεP→↓h ∩R%$αααλ¬~∞↑h⊂ &∪⊂6w`$els @
C\Ae∃Cg←\αβπ |¬0~λ842`)p∧@A←β;9↓β|εε/⊗≤¬~-⎇@εE∃
∃⊂⊂⊂λ0p∞d↓[C@;Lεπ.f≤LRπε X
.⊂7p↔n da`)∧AgiEUGike∃`
β'p∧ε
πlX O∀→y0↔→y0v⊂≥p|W
0≤@pπbαα∧
FG<h⊂⊂[⊂)&&λ4¬`∨I∃XAGC8AeKCM←\AC ←khAαKSM↓∧¬w>r∧λ n <X=
≥{C"Ggβ≠⊂⊂λ⊂0w2λ4¬anipp @3∂#∃β''→β ?⎇`λ L=_ ⊂≤βtr`+α≠S@/,X d
8π⊂ ! rery genep¬C@1∧εv∂Jd∧hR%%"αα∧λ⊗rε← ⊗oεLTε}H≥~
≡h→y-l<X;
≡≤∧P )pεAiQ∀AKC@≤∧RαQ'cs@Hλλ∧
~~0→H3rw2\αa`→Sβ#eβ←∂→β∪↔n{;OS⊗ S↔⊃∧∧'JπM Rε.≤8 $∧β"H∧∧λ≥z.Mλλ⊂≠Z4qt the RLL p KC4~∀@@ACE@≤εG,8⎇→,Dλ≥~ Tλ≠;lL8ε⊂⊂≥4π Handl@∀ABAEI←CIKβ⊃β∂3∂≠@~ε|dππ⊗|-F.o5`λ↓QHλλ∧λ9H⊂∩↑0p
pLe of the Mo`if@%CECYαKSeβ|∧bε∞βH∀IIλ≠;lL8ε⊂ )pεAMC
hAiQ¬h@Ai!J@A¬1_∩)α↓↓βS,∧⊗jε=x
-Lβ"OGgβ⊂⊂⊂λ∀0w2λ24r)
eac@%YrA[=ISMr↓iQJAI→_Ai¬`∂-βLsS↔K∧ε&/&↑ π&@h_p∀_w3rP≥42P ,ow
l@∃mKHAα≠?;S⊗{1β?2βS#∃∧k?β↔bq↓αJdaβCπLε2ε6β|@⊂~z9P &lexi@ SYSidASL@↓iKe[L~∀@@AWL@↓caCG∀@AeCQQKd@↓iQC\AiS[∀X@@@4∀p→yβ`ααα¬
FFO4 ↔4→>≤
L8∧w2Y⊂4w Xπ⊂∪↔v Q1αF gπMm∪?S!α1α/3∞CI1α≤¬v 4∀xp∀WTεE∨∂≥⊂⊂⊂λ0p∞d↓aCeI%GkYCISuKH↓S\A↔≥eKS]∃`XA¬1→:\R4∀@@@↓)↑@A=H ≠O,εBαπM Rαε≤LFO&≥yf∞b∧
7ε∞<Tπ⊗/≤X
. ;90↔≥9P RLL
*** has the Capability to igno@IJ@A∪9iKe→αK@∨α}4αβ∪Vi0hR%%"αα∧
7&@|X9lT≠8>
≥=; ⊗λ8¬siNe a @⊃K[C]⊂AaCO%]NAC1K←eSQQZ\~(|p→yα↓↓βW≤∧W4_(⊂∩→vpw2λ80st[3P0v→wy4j~4¬ to
α>x|@@@↓SO]←IJ@A∪9iKe→αK@∨α}4αβ∪Vi2π∨Mz&∞≡T
V∂F≥↑VjR¬
6.*λεtm]=~β∧λstS K+J#!! JJE!(λλ∧λ(≠8--|H≥l\8{Y.≡h≠qD
S∪λ
≡h~=∞P60qZP7s⊂_P⊂:iYy⊂⊂3≤αont-end.
:6. RLL haq several majoR weaknessEq(λAC1XAgi∃[[C]≤AMe←4ASif↓S[@7∂#WKπ'I84'ccrα∧∧∧O'4
F∞≡4
v $_(λ∞↑y<@∧ \[{NE9;Y∧∞≤[⎇L\λ_ ∞<<Z;n↑h≠∩-]=_=
≥{KC!$λλλλ≥≠λλ =y→( mβy⊂:~2P9x~v6⊂6[r2v⊂~0r⊂*≠P2w:→y2r⊂~w⊂0@ Lisp-like fh∂e[¬h\
∀@@Aα↓H∂?? ↓β≠K}sQ7↔v!↓β←⎇+3⊃↓εCπ[∃αβ≠π∂Lc'S↔ ↓βS#*↓βOg≥#↔5↓ε#↔O'>q↓β Hh)↓↓αβOW∨>+OS'v9βπC∧ε&␈π-≤↔&* L↔&
∞8
∞∞αqz:\2yP0[2⊂0v→wy4`4his.
α[[Xε∪∩AMQSMi∃HAiQ∀A←eI∃`A←L↓iQJA9KqhAQo↑Aa¬eCOe¬aQf\%;; 4hP4))RP%↓↓αα¬βSFKK⊃β>+π/;-≠@~ε|d¬∀dD ↔
ε≡N2αεL≤6Zα
xbαε=yg∨',≥⊗w'5`αH'ccpJ∧∧α¬&
≡2ππ-|&f.T∞v∂~ ←ε∞yy<L≡→9⊂_<P!&∪⊃yP⊂≠0qu@λ5s⊂⊂_ww9j≤αa`∪]QfP→↓h)↓↓ααS#∃¬∩21↓∧εF.∞T∧ε6@⎇;Y∧∧≥~_.Dλ≥≠mtλ≠=,=λλ⊃N2rr7[P⊂3'\αcedAiQKαi↓βSz↓βOC,s⊂$ α↓↓β∂|¬g=9→4L≤[→(∞M8εrP→2qtb~w3P 7hich↓` ↔πd¬GJπ|≡2πε Tε⊗/>@λ∞2x92\p¬ftatign
λ∧@@@↓C]H@AG←]Q` >D∧π∂',X7'<Y+D∧λ⊂p↔[p¬ @∃q`∪↔⊗sπ1↓∧∧6}w>L⊗NwN4αε@8∧st≥⊂⊂40]2@
nap¬eO@>+⊃βSF)βO↔∂∪∂!β∞s⊃β#,¬Gε.Dλ
8εP &in`∪GαA↓βSout @QCgWf↓YS@/*↓α←#∂!β'M∧εFF*∞8 n↑Xy(
|β⊂:4→P9x )lhλD\4⊂⊂∀!∀ααα
Mε*ε←∞ε/⊗≤X L<αP7`& the RLL p KC4@AoSβ#!↓β&C∃↓β≤εεNfD∧ππ⊗βy|L≥ εE⊂λ⊂⊂4f≠8¬stratedAiQCP@Ak]⊃Kd@AYKer@↓iSOQP@AiS5J@AGα{;OS⊗ ';S~↓β¬β≤¬⊗oεLX AQHλλ∧
α0w3]psrP≤zqt_yP"fVa`g or LISP c@=kYHAα ∂#',εf*π,Z7.gL4εn␈,Tαπ∂]_λmv<FEλ⊂⊂⊂ 4haf RL@_\α↓α'Qαβπ3Oz↓βK↔L¬f&←,8 ,D≥~→-≡H≥P∀Y{P:4_z⊂1:Zv24g→β an↓KqaKβ∪P (αHλ∧∧≤}0→]2p
IpεAC\αβ';∂⊗+7.β]_-D_8λ 0ph∂CG Ai↑Aα≠?7C,εF.v<U`hPβ"VkmDd`3 thi@LA0@=∧∧g-βvP \82w2~|⊂"←H⊂ f nkt, whad↓SfASαqβS#∂!βπC∧∧Vv&≤ε∂a≠4εnFBα ∀@@A/v{←3↔&;∃↓ERα5Y5⊂∧ε&.\N2εNnMr∧keP %@∧¬∀~(∩@@@↓)QS@~βC'↔≤∧Rε@yH⊂∃[5{v %dge @%`
βO& S'
∧[;/←d∧V&>Tλ
=λ⊂→→x92iYw:0∪
λ a pi@∃G@∃β|∧bπε Tε'⊗≥_ L≤βrP .etwo@IP
β'p∧π&FT
7εNβ≠λ∞∞Yx[ ]+Hλ ≡λ≤p/≡h≥~ ≡β"H∧∧λ≤⊂∀\2P&K Y⊂3 %e` fAαK;C=∧εεOεT∧∧k∩T∧ ⊂λ4p∞ the netgop¬V@9ααS#'α4αε↑mx
mL9→y!QHλλ∧∞{y0⊗→⊂⊂12H⊂:y`%d to he`→@↓IKMSαs∃βSF)βC?∧¬vf@yx P≠pε the d`%¬S]CO∀AP≠↔';?K1Q"αα∧
6zε≤@λ =⎇;⊂∩λ12P 3earc@!K@@8hP4(∀∧αα¬)IBα¬,Zπ,<y0↔≥0z4`/n. This is Handl@∃H@Ao%iQS\α↓β@& Tαπ8π4`4pε~)α↓↓β≠⊗ 7/⎇x MT∧ @U`∂'lpλ∧∞αp∞i@Q`
↓β&CπQ↓∧ε&/π,X l]]λ∪&E,+β!∃∃∃⊂λ⊂⊂&@6-2 the "f@∃K@∪M∧¬⊗wεt λ∞2r0z~ww⊗⊂_w2⊂ 4he manhol@∀AG←]
Kah\4⊂ `3βH∂ MXZdXAβ##∃↓⊗3↔.L4εNwMt"π⊗]Hλ.M9{@⊗λ0p∞d↓c@↔Q∧¬v $_;⊂⊗λ842P≠pp∞holes.
λλ
(J↓↓↓αhεbk⊂β"B$∧λλλ∧ <x ≥λ⊂⊂⊂⊂λ⊂⊂⊂∀⊂w<fp[47v %)
∀∩@@@@↓
KKIM∪]i↑h@@@Q4lZbR4⊂λ (αB(∧∧λ∪ ≠ X@
Isah@@@@@@@@!β]s≠¬]Q←Yα)$4!∀ααα∧∧∧6.\N47⊗β{ ≥λ⊂⊂∀&M⊗Y∀FB∧¬∀∩@@Aβ9s⊂↔πvC?3∀hP%↓↓α↓↓α↔F 7C3,ε3@$λλλ¬ -K _K⊂
,4dR4PI↓↓↓α↓α&↑8λn4x:4[w_
The c@1CgfAα{⊂∩ε≥H ∧
8;Z
⎇→<kAQ@εE∧H⊂⊂⊂#→pr0∪Inpo
@∪@≤∧∪@$λλλ∧∧λλλ¬λ9↑4mM⎇
#!∧P⊂⊂λ⊂⊂"2\βcri@AiS@?qQαS#Lε2π≡Mx
∧
αpp⊂@LAMe←αiβ .≥mε}f↑4π&@h≠8-m≠{⊂∩\β( 4PI↓↓↓α↓α'nhW.y*H∧∧λλ⊃L\9_ c≤αh∂Z~(∩@@@@A Kα3';≡M⊗}sαHλ d∧i`'β↓β∂?&)βC#∂!β'lM⊗≡∂LX d
≠x @≥4π dedqce the @YCYkJ4⊂ ))PH$%↓α↓β >dλ
(≤p⊗≠z⊂ @∀X ≥eDπ&FTλ ,≥X∧7`,e i`(αβ7πC~β';Szrt4'`∂Ga ∧DPλ⊂⊂7`& p QJ↓
KKIM∪]i↑↓`∂3?α@∞}H≤p↔[p¬ manhol@∀XAR]∀X 04Sqy`0α""$∧λλ⊂~~2P6p[47v % it @5CafAαK;@&ukPhPβ"C!⊂⊂⊂⊂∩w0∂`/1K@∪∨*↓Iiα∞c1αC,ε&n∞βY0↔≥⊂)z7\αage Ta`≥WLAβeJ↓ S@/,∧B`!α@
Thi`&↓P∂;|¬{ \α3rP_pp∞ be @IKaeKβ≠↔;S,∧Bαε]_
<Hλ∞≡_8
4Xpp l@d@A←@⊂h ∩α∧∧ππ⊗|8 ,Nαy0v≠<P⊂ !nd @5KC@;~↓β@& ≡Bε∞β≠λ∞M→(⊂_→y0
anent @MiP∨K∞;∃βS∞s ∨~
↔6(β"H∧∧λ≥x-Mα9P /p∧AISβ#∂#↔~βS :
_ Nzy2P≥40p∀↓`∂C'd¬G4≥z0⊗≠⊂12P_ww:0Zw2r.
~∀(TT%α↓↓αJdaαK↔∧ε&/≡]nF∂&≥x E@⊂⊂$`. RLL thi`&↓o←kYα!β ∃∧ε&/π,X l]]→0∩λ0yFE∂≤ε0≤∩@@A∀b1αK,επ,<y0↔≥0z4`/n. One way to p¬Kae∃`∂↔n@λ∞M~8 P~w⊂ ∩LL involve@L~∀@@A`∪←zβW;≤N3@$⊂;↑*>≠x 0Yβ` )C9P
βπv!β¬β,¬fO6↑.6∞b∞hλ.4pq6→P⊂λc@¬YP∪↔ ∧πBJaQ hPα(λ∧∧⊂;↑* <[8-l8π:)]4πrageP C],~∀%α↓↓↓↓∧#↔O∂⊗KC@&≥x D∧λλλ∧∧λλ∃
(_p⊗_yyP /d∧ACYαaβC↔⊗kπ;↔w!βOS|ε&∞y(⊂~_w0 s.
∩@@@@AU]Sm αc↔7↔w#@≠R∧∧ααα∧¬πBHβ"C!∧¬∀∩@@A@h ⊂J∧∧αααλ¬0↔~{$p∪@∧p ↓↓α↓↓↓↓α↓↓↓↓D ;fC,ε&n∞βY0↔≥)z7`2a`∂K& ;-⊃Q Jα∧∧αα∧←_F.X∧w4[3iv /ts: ⊃.s'Z'α8λ$
~;9)@pεStop¬COJ$~∀%α↓↓↓↓∧kfπO≤∧W.α4w`.alSl@=ift@! S@/,∧CzHβ"JE%@∧P⊂λ⊂⊂⊂"→yqy4\84w`.8∧@@@@@@A¬YP⊃β4∧⊗∨'4λ nMβy2`$ here are true d¬P∨I∧∧⊗f@β"OGgβ Descrippio@8p ↓↓α↓↓↓↓¬##∃β4∧⊗∨'4λ nMβy2`$ here are true d¬P∨I∧∧⊗f@β"B!⊃ ∧P⊂≤2y6p[2p∞t↓`∂S?⊗ ↔*∞L⊗v←5aP@!(λλ∧∧λ∃~-\αgs)]4πrage: @@∃` .≥lVwQ!∩αα∧∧α∧ε≥<V#{$∧ααα∧∧ααα∧∧α¬ Q!PBα∧∧∧↑vβy{ \α3rP ]⊂$`& The @πQK[%GC@1∧K@~∧α⊃K↓Q@∧DP∃42w Te`→X↓)QJA=EgKeYKdA≥=hA)↑↓ K↔∂##∃αLεB`!α@
Thic hπ]OO1K@∪∨*β'Mβ≤¬F.∂/∀ππ⊗|8 ,Nαy0vλ⊂0w2λ⊂4qPλ0s⊂⊂~vx7`2ta`≥h4⊂@@@↓oCe]%]NAi!ChAgαC?W∪ ∧ε⊗* ⎇↔6.dλ↔4≤{p↔[⊂0yP≥42P!Z2p
i@
CXASβ→β'∪,¬g&Nm_V"pβ"C!↓(λλ∧
S∪λ
,<≤Y.≤αs:0]4p∂n∞ The iff@=aP↔π&K?9β≤∧⊗rε,Tπε/∞,W<αs:2Y⊂0yP_w
BLL ru@1JAC@~β@≡F}⎇bε⊗]H nwA"C!↓(λλ∧
];⊂∩Hβ33 $4⊂∩@@@@A∪MBt@@@@@@@@@@@Qβ]e%`↔3*H4(∀∧ααα∧ ⊗5',YGM⊗]LW6∞nG"αα¬λU
αx8
]88x-D∩⊃J%⊃ B(∧∧λλλ
M→;U ]≠∃<l↑NHλ∧∧λλQ
t≠[u∧ \Y8.M→(∃
(_p∀→vpqp[⊂PQεB∧P⊂⊂λ⊂⊂( 2ioriTy: High
∩@@@@A=])CgαYi↓↓α↓↓↓↓α↓↓α'nk';↔w"∪πl|W@ C"GgMHλ Mβz2P≥42P:[4z⊂ !bkve pπQ←oLA←]YdAoQCPAiQJ↓kgKdαβ←?Wd!β#π4∧Rπ&tλ
]≠λ∀IIλπεE∂≥≠⊂⊂∃42P9↑yz2fH1pw≠7{P![vx:j→P:42H;0v:YP37`2 iany additional slOts as neeDed&
>:> The varaouq slots which stkre exec@UiCEY∀A→∪'@AG←I∀~∀|@qq↓↓β≤¬w.Y<t
⎇Yλ∃
t≥~→.<αP22Xv0y0]4ww9JP0y2H1wvx≥z2r in this way.~∀4∀⊂≥I8j?∂QiAE↓↓λεC#@≥\↔πJ ≡B¬∀→hBm,i≠αM,Xf/⊗]l6/~↓Q%&{$
$$h_=∧
u+0)⊃ ¬!`#8∧A[CIrACHααJε: jV:&@h($
↔+GO↔d¬B∧∨,X
-l<NC!! ¬⊂⊂λ⊂⊂⊂⊂λ$p∞ @QQJAGα{@↔⊗\8
≥{\h mβy⊂"≠w⊂+p]2y6p[∪yP2≠qzvr[8∩⊂,[zP6pZr@
re@→KeK]
JAi↑↓'[Ci XAπ∨I→_@9αα∪ :∂→w*ε ≡f*πM Rπ>
x Q B0⊃Zz0z4[w⊂3 /p∧AiQ∀AaCaα+A`:∧
FF∞m>2`HαC"A⊃ "3,≡↑(⊂.D∀X;LE5;Z/↓ ¬εEβj#P&Pi( @Rand-Unix 14:3827-O@
h~*≤zJ21∧εε∂ε↑!PEN|Tππ⊗|,⊗⊗g∀λ
l≥]λ⊂→[vrP)]q9r`4 h∂LAβ##'MPh $
≤k'S!bα∪π[L∧B∧*eDα∧≤z)Db∧β8;N\9 λλ∀∀⎇≠n 9y( ≥Yλ⊃M≥→(∪,≥X9y-\αs: System
∃M=` α∂v{←3↔&;∃α ∂≠↔M bαOSπv3?K⊃∧C↔WKM≠S'
¬βC >|,⊗nn≥lr¬π-x
L\⎇ β!)9;;d ∀⊂λ⊗N_∩P_(Working Paper$XA
←β3↔7 ,ε"β ↔αα`@ ¬-@11 pages]
Anything e`→gα)α%β≤∧⊗rπ∞-w6NLWphPβ"TN↑|c"@↓H(≠⊂∀\βt o@_A`∪#|ε6*ε≤LFO&≥x L≥λ≥P⊂[8¬es whic@ AOKhαβCπO≤∧V"πMqP@!1y0~∃αa`→@,∧Rb¬∞X
@0p `+α)βπl@λ @90 e@9If@8hQq`#H|W$X∧r`,d and PutFi` @3 ∧π>Nβ≠λ∞www have a si@5SYSCHAQS@≤εCs@LπεEβE*42H8∧hi@IHACE≤A`∪=∧;↔R[∞cW*¬Pλ∧4πthep∧DASαqβ .β|p~λ3:w1]4p∂ns - i@LAC@9∧εVv@|Y→.2r⊂ ,ist
(actualli an FSet ∩Aβ;# ?<Tε.f]\Vw≤h⊂⊗X|P12Nαλ
(hQ↓↓λh∃≥λεa`PβHE @LbAf@⊂¬0∩rdλ i@∀P⊂⊗KP:44\β caupπ@↔M∧εFF* ≡F}jλhλ.z⊂
C@¬GQJAβ#=β *βCπO≤∧V @ ¬∧`4o CacheValu`
XAα{9β'αN2α↔⎇∂∩$≠~0→]⊗⊂3 /p∧AKC
PAgYα{Q1β≤¬∩`!αE⊂∃¬0p0iλαP9XH9Y⊂↔ α. sN) ~Zα↓β@&]H ∞P:42H3rz-va`→kα+@~∧βSu∧∞α7P #ache the @
←[akβ#↔ Q!↔6∞β≥0∩H4πf @¬]rAgαc?Qβ≤¬∩`!αE⊂⊂
⊗agfT*j"P≤β1 s2 ...↓`∞ 2∀∧αααβ+ ≡M→(⊂∪Yz⊂
v@¬Y`↔↔~β←'MDεv@⎇λ⊂⊃≠z42`2 computing p QJ4⊂λ'[∞cW*
x D 8π<P≤βlt @MRvASα1β@& Tπ6∞β≥0∩H4yw't stoped, h¬`↔O ∧ε -βy3r]⊂4p∀∞
(IG@≥∨I
P⊗∞ ~"*∞6∩π≠$¬b`%H≤sE∀λεV@=42P 'et ≠mα 3@.↑4π>Nβ≠λ @'j⊂ 5pπ@∃β&C∃βO&{@⊗.Dλ
L≥≥9#!∧p∂f any @MYP∨Q∧ε6Jαβ+ ⊂_8¬t @ICiQKβ⊃β@>≥H ∧ {{<∞↑→(⊂~~4πse va`→@.+@~ε≤∧h
l99→,E@εE⊂λ∀)`c⊃i` OT s1 @Ld@@9p¬bπ≤βJ(¬UαP2`!ch s@$AeKC1YrASβ→β¬β≤¬F␈#4λ mt→≠p↔ z⊂17]42y=4π
confir`~Aβ##'Mph ∩α¬
4 4X¬3I~α⊂:XH8¬2 .,∧\Ak8R@@5h∧ε.∞=∂.J
_ d∞Y8;
O(_ ≡]X∧p∀8~∀ZZαh4*@9mw&* ∀ε∞j∞N'NNβY`≡MβP0r≠x:⊂ 4he c@=]`≠↔w#'?9∧εFF∂DλλM≥X8 <H1ww2~z4w`.pεAEJ↓S]ISα≠πS↔ h ∩ε,ε(∞↑z;Yd∞{{9$
β0vrK⊂892Yαixe@⊂AEr@,AP∨Iαi1β∪,εε.vM_ L@P7w pπ@↔n8 %@⊂⊂$`. genep¬C@1∧¬vv@≤∧FEλ4πne d¬P∨Kh∧αF.tλ -≡~→0→λ∃oooH4πr -←←←) wi`→X↓EJA]∃G@↔O≤∧↔/+λ⊂⊂\β the h∂iQ∃` βO,¬g<αP4`3
the o`-α+@⊗∞β≠λ L9X=-Nα⊂∞ Fh∂dAlExamples will be ignored for all
units U, but that V:AllIsas will be accepted EXCEPT WHEN V=AnyFrog.
I cuurently have no use for such a "feature" - do you?
Another direction may be to have forms which are evaluated during the call,
will appropriate bindings --
(GetValue 'Fred 'Friends '((IGNORE-CACHE =Fn fn#37))),
where this fn#37 will be applied to the unit and slot being considered at
each (recursive) call to GetValue; and its values would be used as the set
of slots whose cached values should be ignored. A slight variation of this
would be something like (... ((IGNORE-CACHE =Pred= pred#82))), where pred#82
would be a predicate whose nonNIL response meant the argument should be
"ignore-cached". Once again, this sledge hammer may not ever be really needed,
but it has been considered.
Future directions:
(I'm sure I will need more of these values; but am waiting for a forcing
example before implementing and documenting those options.)
(i) (USE-VALUE (u1 s1 val1) ... (uN sN vN)) meaning "pretend"
the value of ui:si is really vali -- don't bother to compute it.
(ii) There's also some hassles when dealing with those *DO* special
values -- should they be treated as simple "syntactic" values, or
"evaluated" -- ie how do I store the "value" (*DO* FSeeUnit SofU)
as U:S? As I said, more on this as this comes important -- unless
you've some insights on this whole can of worms.]
-------
Onto the putting functions.
There are basically two types of values. I'll resent the primitive ones first:
The final argument is a set of zero or more elements, each od the form
[These apply to any of PutValue, AddValue, DeleteValue, SubstValue]
-VERIFY -- there is no need to verify that this value is appropriate, or
that this slot belongs on this unit. (Yes, this may indeed be
confusing two distinct functions. Eventually I worry about this,
if I have to.)
-INVERSES -- do NOT now add on inverse links (this is useful when this
particular PutValue was itself adding backpointers. If not for this
facility that process would always lead to an infiniTe loop...)
-DEPENDENCIES -- do NOT do the other misCellaneous KB updates which result
from thiS modification.
[This only applies to PutValue]
+ALWAYS-UPDATE -- go thru the motion of adding inverse links, and other
after-put-value functions after performing an update -- even if the
value seems NOT to have changed. (Ie pretend the old value was really
RecomputeMe.) This is needed to handle the case of unit
iniTialization, when valuas are fIp¬ghAMS[aYdA+α[A+)-β1+ HA=]i↑AQQJ@~(∪kMSβ!1βπv!β3π&+Iβ#∂3∃βSzβ ∃β∞≠S@.≥MGJ¬∞ZE ,9≥9%\ C"AQB6u
<y(
⎇[≡( ≡≤≠⊗$∞≠h⊂,L∃X;∞\+λ⊃ ]→=→*l9→1%D H∀n\\⎇∃L≥≥97!QHλ
h9q4∃*H+23I~⊂∧`fλ⊗VP+Z0z⊂)Z5zv"λ<wp∃ do when you've been th∂YH↓iVAC⊃HA←\↓B~∧∪9KnAm¬YcJX↓,XA←9i↑A*i&AoQ∃\AiQ∃eJASβ→β;≥¬3π3W*β? α+RM|4PJS#↔⊗)βO↔,iβS←zβC?O≤K '3M#'πMβ!P@Jε∃∩ε&tλW6//_
9Y`⊂≡wzP!Xw⊂:7H1wvx≥z2P*~2P;0[:rP'Yα U*S,
α and theN addon V.
∩Pβ⊃%βOLkC3e∧;=β?pa↓#3. ['≠8∧¬+U4
Vv≡⎇↑π/&\@
$∞z=~∧∞~→( ≡|⎇4L≥Xy(∞M_=β!↓(λλ ≥↑(∪ml(→P→≠vP77]P7w≥t7P 7ant`&4⊂∩@@↓iP≥β4¬⊗v"∞Mε*πl≥G.(≠p∪λ*Y)P≥tp l qpec@%H '∂∞c3eβ∂≠ ~εmx D
= λ∞↑z;Yd↓ ¬∧Pλ⊂#r`4T¬C@3αX 'P;t4Xt⊂;t[4∧ now have to compUte i@PXλ (αB(∧∧∃~→$ <|p→]vx:4[w⊂4`3 phat S:To@π←[aβ+S∃β>K3 "
mw:ε<≡F≡B∞MεO~
lW:¬eaP@L≥o↔>∂∃DεO"∞NW-β9P']z⊂:4_z⊂17]4⊂7`& phe@MJAGCMKfAGα{7*∞X ∧¬+(⊂∀→w1rP≥44p∪
λ extp¬BAaα @⊗∞β90~→y↔εEαm`∞o@QJA%∧∧&.f≤X
LT≥~→$ ⎇<\L]]λ⊂_≤4πgrams wilhλAC1oCsF↓G←[aβ+S∃β&C∃β[∞cW*
_ D↓α@
@QQJAgαc?QβO→βCKL¬VO&≤h $¬+(⊂⊂\β thipεA[Kα ;Mβ&C∃β[∞cW*
_ d Xπb`.try @=` 4PJ0⊗@q;]∞4ryVλ22x %nding h∂\Aβ##∃β4¬w-αpr o` Ai!JAgYα{Q9↓¬##'M∧¬↔4≤≤[l,8[⊂≤H∧¬∀∪β##∃β?∪?;≥∧∧↔ππ-xλ,=λπ↔.]
∀@↓_ 6[∞cW/4¬Rj∧α;@⊂→β` @;,ε&∞b
x LT≥x;NNh≥≠d 9→⊂≠w⊂5 5qt o@9JAmC1k@∃1¬11βSzβ¬β[∞cW*
x AQ@∧j]∀Tε Howev@∃` βSF+C∃β∂∪∃βSL¬V/~
x LT≠8>$∞βpw:λ87P !dd a↓`∂3↔8∧ε}H≡uM∨β⊂0zβE o@9G@∃9ααS#∃¬βWKC|ε6*ε|dπ&F≤∧h∞l8ε0∃@∀ASfAβ#=β∪Lε7&NβY⎇-≡zλ⊂~~2yrP_pyr`3,∧⊂∀!→f␈&Tλ
<h⊂∀\β we@1XAIKα3';↔ π⊂⊗@|H⊂⊃≠z4⊂ Y2+0v≥p¬ and De@1KiK4∧⊗g9(
@ bp h~(∪[C@Jβ3↔π ∧π&@h_p↔[3:y`)on f@=` αO,∧'∂%l≥G.+λ⊂∀Yα we wa`≥hαβS :∞,Wε@_8p∩H'⊂; !lp Kf4⊂λ'←LεFB∧β(⊂≠_v:r`3, when @≤@p|A5p∧α∧}dλλm}<X `% p∂JAαkπeβ≤¬⊗oεLε( ,<H⊂~~4yP /peration
i`≤Aα;↔;↔⊗ 18Q!PBjUP %U+#"I@4πw @→←dAi!JA←@&C↔Iβ'KC∃β|∧bπX;⊂~YyP∞ Firc@PXAE@Jβ←πe∧¬v $≠;p~~{0p∀ion, @¬`∂,4TεvGJλ∧⊂~]+0v 5e should @-]P∨]∧∧⊗wOM
⊗v: ≤&␈/Dλλ,L~;Yd
8π; %p¬gKf|@A%>c0 (αX9n2rP 4hat De`
C@,¬G%π↑Jf∞g\Tπ=≠x
`,d, but things @¬hAiQ%`
β3,εf.b∞8
}8ε2 be tota`→YβH4+≥nfO≡≤-F*πMtπ&FTλ l]Y<X-D≥<p∩\α-`→Kβ3↔1β5+;∂SL¬vw~βHλ ≡λ≤p∀≠zp d↓EJAgβ+⊂⊗6≤8
,]]β"NMβP:2[4∧ @!β+R[πdεV*πM ↔"π|Tε∂⊗Tλ M}h⊂9 M8π3d[8εerses _Aα ;⊃βv{S#'v9β .βx 2Kαλ
*&C∃β≠,¬f∨&≥x NP;t4Xt⊂ 5tVal@UJAGC1Yf@1∧ε7.≡∧λλ.P"2`&au`→@%βWR[∞cW*Dλ m
βzv $
`≥←β9β'lh .⊂:40]⊂:44\β me@¬]fA]=hAi↑↓C@∪⊃∧¬⊗wY<\lT≤≠p∀[8∧ers po @QQKgJ0@\\\4⊃)QSβ→β'↔∧c'/4λ
lT≤z≠n]→λ⊂__yyP+_v:riH44urH r2$[8εerse in↓iQCHαβ↔cS⊗ βπK?+7πnA`hT
x
l↑Y<@⊗λ842`2e a`%∀AaS[∃`
β'w#↔Kl≥Bε7]l7&Nβ{\d∧X¬w7]Q⊂;t_z⊂4iH4εee@⊃KH@ZαiβπlAP@.βt<P≤t7rf→⊂:42H5z42\⊂3:`.ctio@9`
β≠|ε&≡(≥~ ](≥≠d∞_8p→H:42`3e indirec@PAeCYUKf}~(~∃'←1kiS←8pAβYαc?]β.KS#↔⊂∧π'O Tπ&@h_Y$∞_<p→Yr⊂∞
Of course we needa table which @IKYCi∃`
βSF{G*∞λλ.0p
e@QKefAβ;'S!∧εvF∂Dλ
>(⊂→→pr6,CE0
e@¬\@@5hh $ε4∧W-9↑/a⊃2;]L↑\y/a_→<⊂∩[22w1Zp¬s >4∃≥KnαjW;≡A∩αααhλ↓⊃(λ
aQRp@⊗Pww9d\βtency ∩∩$∩@@V4⊂
π∪$K;@6↑.6(H⊃⊃⊂Jα¬1P@(α2v %teInverse ∩∩@V~∃IK[@?4¬⊗v<mx L]9{Y.∞b""!∀λ
c!
8π4`4Re`≥C5K@∩∩$∩∩@@,~∃+]%i∪↔d∧W&.A⊃⊂HHα(λ¬1 O⊃ \X8
`,t8 %α↓,$∀∧αXHα(λ¬1"C"Kd∧egend: @QQJAC `∂.β\p∩H4πf @∧@DVDαβ7.≥n2αm{{uz@λ→P↔\α parametep∧A??|}ACE=mJ]~4∃)QSLAG←]YKegSα{9βS∞[↔Mβ∧¬F∞≡Tλ
-d⊃→0∪_zr0∀←←←Valu`
X@4⊃M@?⊂∧¬⎇⎇tλ
-d≤¬` 5t Add @ KYα+S∃α≤εV↔∨M` D∧λ∧$w→2y4`/p∧AMkαs∂S'|¬g4≥z0⊗≠⊂0p∪@Mk[JAβ##↔dhSπK∃∧;↔SSL¬f 4≥~→$
8πq2H894fZz4s % f`∨e5b\R~(~∀